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About This Manual 


Tlie Development System Reference Guide contains information on the 
software programs in the Xilinx Development System. Generally, the 
chapters are organized in the following way. 

• A brief summary of program functions 

• A syntax statement 

• A review of the input files used and the output files generated by 
the program 

• A listing of the commands, options, or parameters used by the 
program 

• Examples of how you can use the program 

For an overview of the Xilinx Development System describing how 
these programs are used in the design flow, see the "Design Flow" 
chapter. 

Additional Resources 

For additional information, go to http://support.xilinx.com. The 
following table lists some of the resources you can access from this 
page. You can also directly access some of these resources using the 
provided URLs. 


Development System Reference Guide—21 i 




Devrtopnienl System Reference Guide 


Resource 

Description/URL 

Tutorial 

Tutorials covering Xilinx design flows, from design entry to verification 
and debugging 

http:/ /support.xilinx.com/support/techsup/ tutorials/index -htm 

Answeis 

Database 

Current listing of solution records for the Xilinx software tools 

Search this database using the search function at 
http:/ /support.xilinx.com/ support/searchtd.htm 

Application 

Notes 

Descriptions of device-specific design techniques and approaches 
http:/ /support, xilinx.com/apps/appsweb. htm 

Data Book 

Pages from The Programmable Logic Doti Book, which describe device- 
specific information on Xilinx device characteristics, including read- 
back. boundary scan, configuration, length count, and debugging 
http:/ /support.xilinx.com/ partinfo/databook.htm 

Xcell Journals 

Quarterly journals for Xilinx programmable logic users 
http: / / support.xilinx.com/ xcell/xcell.htm 

Tech Tips 

Latest news, design tips, and patch information on the Xilinx design 
environment 

http:/ /support.xilinx.com/support/techsup/journals/index.htm 


Manual Contents 


The Development System Reference Guide provides detailed information 
about converting, implementing, and verifying designs in the Xilinx 
environment. Check the program chapters for information on what 
program works with each family of FPGA or CPLD device. The 
following is a brief overview of the contents and organization of the 
Development System Reference Guide. 

• Chapter 1, "Introduction," —Describes some basics that are 
common to the different Xilinx Development System modules. 

• Chapter 2. ' Design Flow"—Describes the basic design processes: 
design entry, implementation, and verification. 

• Chapter 3, "PARTGEN"—Explains how to use the PARTGEN 
command to obtain information about installed devices and 
families. 
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• Chapter 4. "NGDBuild,"—NGDBuild performs all of the steps 
necessary to read a netlist file in XNF or EDIF format and create 
an NGD (Native Generic Database) file describing the logical 
design reduced to Xilinx primitives. 

• Chapter 5. "The User Constraints (UCF) File/—The UCF File Ls 
an ASCII file in which you enter constraints affecting how the 
logical design is implemented. 

• Chapter 6. "Using Timing Constraints."—This chapter describes 
how you specify timing requirements for your design. 

• Chapter 7. "The Logical Design Rule Check/'—'The Logical DRC 
(Design Rule Check), is a series of tests run to verify the logical 
design described by the NGD (Native Generic Database) file. 

• Chapter 8. "MAP—The Technology Mapper,"—MAP maps the 
logic defined by an NGD file into FPGA elements such as CLBs, 
IOBs. and TBUFs. 

• Chapter 9,"LCA2NCD."—LCA2NCD translates an LCA file 
from an earlier Xilinx Development System release to an NCD 
file. 

• Chapter 10. "The Physical Constraints (PCF) File,"—The PCF file 
is an ASCII file containing physical constraints created by the 
MAP program and physical constraints you enter. 

• Chapter 11, "DRC—Physical Design Rule Check."—The physical 
Design Rule Check (DRC) consists of a series of tesLs used to 
discover physical errors in your design. 

• Chapter 12. "PAR—Place and Route."—PAR places and routes 
FPGA designs. 

• Chapter 13, "PIN2UCF."—P1N2UCF generates pin locking 
constraints in a UCF file by reading a a pkiced NCD file for 
FPGAs or GYD file for CPLDs. 

• Chapter 14. "TRACE,"—TRACE (Timing Reporter and Circuit 
Evaluator) performs static timing analysis of the physical design 
based on input timing constraints. 

• Chapter 15. "SPEEDPR1NT"— SPEEDPR1NT lists block delays 
for a specified device and its speed grades. 

• Chapter 16. "BitGen."—BitGen creates a configuration biLstream 
for an FPGA design. 
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• Chapter 17, "PROMGen," —PROMGen converts a configuration 
bitstream (BIT) file into a file that can be downloaded to a PROM. 
PROMGen also combines multiple BIT files for use in a daisy 
chain of FPGA devices. 

• Chapter 18, "NGDAnno,"—NGDAnno annotates timing 
information found in the physical NCD design file Kick to the 
logical NC.D file. 

• Chapter 19, "NGD2EDIF,"—NGD2ED1F converts an NC.D file to 
an EDIF file for use in simulation. 

• Chapter 20, "NGD2VER NGD2VER converts an NC.D file to a 
Verilog HDL file for use in simulation. 

• Chapter 21, "NCD2VHDL,”—NCD2VHDL converts an NGD file 
to a VHDL file for use in simulation. 

• Chapter 22 "XFLOVV"—XFLOW is a command tool that runs the 
full suite of implementation and simulation flows. 

• Appendix A, "Xilinx Development System Files,"—This 
appendix gives an alphabetic listing of the files used by the Xilinx 
Development System. 

• Appendix B. "EDIF2NGD, XNF2NGD, and NGDBuild," —This 
appendix describes the netlist readers (EDIF2NGD and 
XNF2NGD) and how they interact with NGDBuild. 
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Conventions 


This manual uses the following typographical and online document 
conventions. An example illustrates each typographical convention. 

Typographical 

The following conventions are used for all documents. 

• Courier font indicates messages, prompts, and program files 
that the system displays. 

speed grade: -100 

• Courier bold indicates literal commands that you enter in a 
syntactical statement. However, braces "{}” in Courier bold are 
not literal and square brackets "| |" in Courier bold are literal 
only in the case of bus specifications, such as bus |7:0|. 

rpt del net= 

Courier bold also indicates commands that you select from a 
menu. 

File —> Open 

• Italic font denotes the following items. 

• Variables in a syntax statement for which you must supply 
values 

edif 2 ngd design name 

• References to other manuals 

See the Development System Reference Guide for more informa¬ 
tion. 
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• Emphasis in text 

If a wire is drawn so that il overlaps the pin of a symbol. Ihe 
two nets an? not connected. 

• Square brackets "| J" indicate an optional entry or parameter. 
However, in bus specifications, such as bus 17:0], they are 
n?quin?d. 

edit 2 ngd |option name] design jnmie 

• Braces "| enclose a list of items from which you must choose 
one or more. 

lovpwr ={onI off | 

• A vertical bar " I" separates items in a list of choices, 
lovpwr =jonI off | 

• A vertical ellipsis indicates repetitive material that has been 
omitted. 

IOB *1: Name = Q0UT' 

IOB 12: Name = CLKIN* 


• A horizontal ellipsis "..." indicates that an item can be repeated 
one or more times. 

allow block block name loci loc 2 ... locn: 


Online Document 

The following conventions are used for online documents. 

• Red-underlined text indicates an inteibook link, which is a cross- 
reference to another book. Click the red-underlined text to open 
the specified cross-reference. 

• Blue-underlined text indicates an intrabook link, which is a cross- 
reference within a book. Click the blue-underlined text to open 
the specified cross-reference. 
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Chapter 1 


Introduction 


This chapter describes some basics that are common to the different 
Xilinx Development System modules. The chapter contains the 
following sections. 

• "Invoking Xilinx Development System Programs" 

• "Command Line" 

• "Reading NCD Files with NCDRead" 

• "Terminology" 

• "Supported Platforms" 

Invoking Xilinx Development System Programs 

You can start Xilinx Development System programs in the following 
ways. 

YM 

• Enter a command at the UNIX command line or on a DOS 
command line in an MS-DOS” 1 Prompt window (Windows 95®) 
or a Command Prompt window (Windows NT®). 

• Invoke a command from one of the following Xilinx graphical 
applications. 

• Design Manager/Flow Engine 

• Foundation Project Manager 

• Timing Analyzer 

• FPC.A Editor 

• Hardware Debugger 

• PROM File Formatter 
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Note: The graphical applications are described in separate manuals. 
This reference manual describes only the command line interlace. 


Command Line 


Command line options ate entered on the command line in any 
order, preceded by a hyphen (-), sometimes preceded by a + (plus 
sign), and separated by spaces. Most command line options are case- 
sensitive. When an option requires an additional parameter, that 
parameter must be separated from the option letter by spaces or tabs 
(for example, -1 5 is correct. -15 is not). 

Fills are position-dependent. For example, par input. ncd 
output.ncd freq.pcf is legal: par input, ncd freq.pcf 
output. ncd is not. File extension use is case-sensitive. All file 
extensions (for example, .ncd) must be in lower case for all command 
line tools. 

For options that can be specified multiple times, the option letter 
must, in most cases, precede each parameter. For example, -1 
xilinxun synopsys is not acceptable, while -1 xilinxun -1 
synopsys is allowed. 

Options can appear anywhere on the command line. Arguments that 
are bound to a particular option must appear after the option. For 
example, -f command file is legal; command file -f is not. 

When you enter the Xilinx Development System application name on 
the command line with no arguments and the application requires 
one or more arguments (PAR. for example), a message appears 
consisting of the command line format string. The format string 
contains the following symbols, along with literals. 


Symbol 

II 

II 

o 

, (comma) 
- (dash) 


Description 

Encloses items that are optional. 

Encloses items that may be repeated zero or more 
times. 

Encloses a variable name or number for which you 
must substitute information. 

Indicates a range for an integer variable. 

Indicates the start of an option name. 

Indicates the start of an option name. 
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Symbol Description 

: The bind operator. Binds a variable name to a range. 

Logical OR to indicate a choice of one out of many 
items. The OR operator may only separate logical 
groups or literal keywords. 

() Encloses a logical grouping for a choice between 

subformats. 


When you enter the Xilinx Development System application name on 
tile command line followed by -help or -h, a message displays that 
explains each of the options and arguments. For example, when you 
type edif 2 ngd -h. the following message appears. 


cdi£ 2 ngd: version 2 . 1 i 

Copyright <c> 1995-1998 Xilinx, Inc. All rights reserved. 

Usage: odi£2ngd (-a) (-r) (-1 <l»brary>} f-p <partname>) <cdif_£ilc> 
l<ngc_filc>l 

-a Add PAD'S to all top level pert signals 


-r 

-1 library 
-p partnarre 
<odif_filo> 
<ngo_£ilc> 


Rcncvo ICC preps fron the design 
Design is built from <library> 

Override/dcfinc pert name in EDIF file 
EDIF 200 format file 

Output '.ngo' file. Default is <infilc>.ngo. 


To redirect this message to a file (to read later or to print out), enter 
the following. 

command^name -help >& filename 


For Xilinx Development System applications that have architecture- 
specific command lines, enter the application name plus -help (or -h) 
plus the architecture to get the verbose message specific to that 
architecture. If you do not specify the architecture, a message similar 
to the following appears. 


Use ' <appnar#e> -help <architecture>' to get 
detailed usage for a particular architecture. 
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Notes about Screen Messages 

<m/SM.ncd|> indicates that the .ncd extension is optional but that 
the extension must be .ncd. 

<infile< . xnf» indicates that the .xnf extension is optional and is 
appended only if there is no other extension in the file name. 

Part Numbers in Commands 

Tine EDIF2NGD, XNF2NC.D, NGDBuild. MAP. and XFLOW 
commands have options to specify the part into which your design 
will be implemented. A complete Xilinx pari number consists of these 
elements. 

• Architecture (for example. xc4(XX)ex) 

• Device (for example. xc4028ex) 

• Package (for example, pq208) 

• Speed (for example. -3) 

Tire following table shows the various way to specify a part on the 
command line. 


Specification 

Examples 

Architecture only 

■KXXlex 

x*KXX>ex 

xc4000ex 

Device only 

4028ex 

x4028ex 

xc4028ex 

De vicePackage 

4028exhq240 

x4028exhq240 

xc4028exhq240 

Device-Package 

4028ex-hq24ll 

x4028ex-hq240 

xc4028ex-hq240 

De vicePackage-Speed 

4028exhq240-3 

x4028exhq240-3 

xc4028exhq24G3 
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Specification 

Examples 

Device-Package-Speed 

4028ex-hq240-3 

x4028ex-hq240-3 

xc4028ex-hq240-3 

Device-Speed 

4028ex-3 

x4028ex-3 

xc4028ex-3 

Device-Speed-Package 

4028ex-3-hq240 

x4028ex-3-hq240 

xc4028ex-3-hq240 

Device-SpeedPackage 

4028ex-3hq240 

x4028ex-3hq240 

xc4028ex-3hq240 


Note: SPEF.DPRINT requires a device name (part number) that is 
somewhat different from the previous table. See the "SPEEDPR1NIT" 
chapter for details. 

You can specify a part number at a number of points in the design 
flow. A part number specified in a later step of the design flow 
overrides a part number specified in an earlier step. 

Tine following list below indicates the points in the design flow when 
you can specify a part number. In the list, a part number specified 
later in the design process overrides a specification at an earlier level. 
As an example, a part specified when you run MAP (the last bulleted 
item) overrides a part specified at any other step in the design flow. 

• There may be a part specified in the input netlisL 

• There may be a part specified in an \'CF (Netlist Constraints 
File). 

• You can specify a part with the -p option when y ou run a netlist 
reader (EDIF2NGD or XNF2NGD). 

• You can specify a part in a UCF (User Constraints File). 

• You can specify a part with the -p option when you run 
NCDBuild. 

When you run NGDBuild. you must have already specified at 
least a device architecture 

• You can specify a part with the -p option when you run MAP. 
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When you run MAP, an architeelure, device, and package must be 
specified, either on the MAP command line or earlier in the design 
flow. MAP selects a default speed if none has been specified. You can 
only run MAP for a part from the architecture you specified when 
you ran NGDBuild. 

-f Option 

For any Xilinx Development System executable, you can store 
arguments (that is, file names and command options) in a file and 
then execute the arguments at any time by entering the -f option on 
the UNIX or DOS command line followed by the name of the file 
containing the arguments. Tills can be useful if you frequently 
execute the same arguments each time you perform the command, or 
if the command line becomes too long. 

You can use the options file in the following two ways. 

• To supply nil the command arguments, as in this example, 
pat -f command, file 

command file is the name of the file containing the command-line 
arguments. 

• To insert certain command line arguments within the command 
line, as in this example. 

par -i 33 -f placeoptions -s 4 -f couteoptions 
design i.ncddesign o.ncd 

placeoptions is the name of a file containing placement 
command arguments. 

routeoptions is the name of a file containing routing 
command arguments. 

The space between the -f flag and the file name is required. 

The command file is an ASCII file containing the command 
arguments. Arguments are separated by a space and can be spread 
across one or more lines within the file. You can put new lines or tabs 
anywhere whitespace is allowed on the UNIX or DOS command line. 
You can put all arguments on the same line, or one argument per line, 
or a combination of these. There is no line length limitation within the 
file. 


1-6 


Xilinx Development System 




Introduction 


All carriage returns and other non-printable characters are treated as 
space and ignored. Comments are designated by a # (pound sign) 
and go to the end of the line. 

Following is an example of a command file. 

Sample Command File 

*conmand line options tor par for design mine.ned 

-a -n 10 
-w 

-1 5 

-s 2 (twill save the two best results 
/honc/uscrs/Jirrbob/dcsigns/xi 1 inx/nine . ned 
^directory for output designs 

/hone/users/ jirrbob/designs/xilinx/output .dir 

iuse timing constraints file 

/hone/users/ jirrbob/designs/xi 1 inx/ninc.pcf 

Reading NCD Files with NCDRead 

An NCD (Native Circuit Description) file contains a physical 
description of your design in terms of the components in the target 
architecture. NCDRead enables you to quickly generate an ASCII 
(text) file based on the data found in one or more NCD files. 

To start NCDRead from the UNIX or DOS command line, type the 
following. 

nedread |-o oulfile name]ftlentimeO. ned \filenamel . ned ...| 

Note: Standard output goes only to your screen if you do not use the 
-<> option to write the output to a file. 

Following is an example of an output file from NCDRead. The 
example gives information on three of the components in the design. 
An actual file includes information on all the components. 

Loading device database for application ncrcad from file 

"testclk.ncd".'tcstclk" is an NCD, version 2.28, device xcvlOO, package 
bg2S6, speed -4 

Loading device for application ncrcad from file 'vlOO.nph' in environment 
/build/bcxfndrv/C. 1 3/rt f. 
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NC.DESIGN <tcstcik> - version 2.2ft 

vendor = Xilinx, package - bg256, speed = -4 
72 comps 

MC_BEL:5 - <C253> ngdid = 5 
caprim * <lut-or-mem> 

comp = <core_inst/counter2/cont<3», cmid = 4ft 
signals on pin: 

Al - corc_inst/counter2/C54/N32 
A2 - corc_inst/countcr2/N356 
A3 - syn274ft 

D - corc_inst/counter2/C65/N19 
bel contig info: 

Inverted pins: 
clkcdgc=CM_CLKRISING 

O=l-l0»Il*-l2>* (-10*11*12) +(20*Xl"X2| 
lutrrodc is EgN_MODE_LLT 

clk_is_invertcd=FALSE r shift_rcgister=FALSE 


MC_BEL:7 - <cora_inst/countcr2/ccnt_rcg<3» ngdid = 5 
enpr lm = < 1 atch-or-t f > 

comp = <core_inst/ccunter2/cont<3» r cmid = 73 
signals on pin: 

CK - ck2 

D - core_inst/countcr2/C65/N19 
0 - core_inst/counter2/cont<3> 

INIT - core — inst/counterl/n224 
bel contig info : 

Inverted pins: 
c1kedge=CM_CLKRISING 

clkinvert=FALSE, resctmodc=TRUE resctcdgc=CM_SRFALLIHG 
resetinvert=FALSE 


MC_CCMP:3 - <core_inst/counter2/cont<3>> ngid - 5, external = 0 
siteparam:I 0 r sitc:-l, 12 pnap:-t, nacro:-l 

Contig String: <CYSELF:#0FF cyselg : I0FF CKINV:1 COU7USED:#CFF 
YUSED:#CFF XU5ED:*OFF XBUSED:#OFF F5USED:#OFF YBHUX:#CFF 
CYINIT:fOFF DYMUX:1 DXMUX:1 CYOFitOPF CY0G:#OFF 
P: IL'JT : D= {-Al *A2 *-A3 I♦{~A. 

G:#LUT:Ds{-Al*A2 *-A3 I♦{-Al*A2*A3)-(Al*A2*A3) RAMCONFIG:4OFF 
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REVUSED:>OFF BYMUX:#OFF BXMUX:*OFF CEMUX:>OFF SRKUX:SR 

GYMUX:GFXMUX:F SYMC_ATTR:ASYNC SRFFMUX:0 INITY:LOW FFX:IFF FFY:#FF 

INXTX:LCW> 

There arc <10> paths. 

17: ff;12| ft pins Fi:Fi F:A1 F:D FXMJXzF FXMUXlOUT DXMUXll DXMUX:CCT 
FFX:D Container |1): 1ft 

43: ft pins F2:F2 F:A2 F:D FXMJXiF FXMUX:OUT DXMUX:1 DXMUXiCLT 

FFX:C 

Container <1>: 44 

69: If :121 ft pi F:A3 F:D FXWJXiF FXMUX:CUT DXMUX:1 DXMUX:OOT 

FFX: 

Container <1>: 70 

89: [f:12] ft pins Cl:Gl G:Al G:D GYWJX:G GYMUX:OUT DYMUX:1 DYMUX:OOT 
FFY :D 

Container <1>: 90 

107: (f:l2) ft pins G2:G 2 G:A2 G:D GYMUX: G GYMUX:OUT DYMUX: 1 DYMUXiOUT 
FFY :D 

Container <1>: 108 

123: If:12] ft pins G3:G3 G:A3 G:D GYMUX:G GYMUX:OUT DYMUX:1 DYMUXiOUT 
FFY :D 

Container <1>: 124 

531: [f:8] 6 pins CLK:CLK CKINV:1 CKINVlOOT FFX:CK FFX:Q XQ:XQ 
532: lf:81 6 pins CLK:CLK CKXNVsl CICXNVrOUT FFY:CK FFY:Q YO:YQ 
569: If:8‘] ft pins SR:SR SRMUX:3R SRMJXiOUT SRFFMUX:0 3RFn4UX:OUT 
FFX:INIT 

FFX :Q XQ:X0 

570: [ £ : 8 ] ft pins SR: SR SRMUX:SR SRWJX:OUT SRFFMUX:Q SRFn4UX:OUT 
FFY:INIT 

FFY:Q Y0:YQ 

There arc <26> delays. 

Pin Types: 

Real_pin=<00> pintype=<0xl0,16> 

Rcal_pin=<01> pintype=<0xl0,16> 
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Terminology 

Commonly used terms in the Xilinx Development System are defined 

in this section. Terms specific to certain Xilinx Development System 

modules are described in the relevant chapters. 

• A device Ls a particular FPGA or CPLD. For example, a Xilinx 
XC4010E is a device. 

• A silt' is a programmable logic element (used or unused) located 
within the device. 

• A compouenI is a logic configuration that will, at some point, go 
into a physical site. Examples of components are CLBs. lOBs, 
tristate buffers, pull-up resistors, and oscillators. 

• A net (also called a signal) is a set of two or more component pins 
to be electrically connected in the finished design. A net normally 
consists of a driver pin and one or more load pins, but it may 
have more than one driver pin in certain cases. A net does not 
pass through a logic block, except in the case of route-throughs 
(routes that pass through occupied or unoccupied logic sites). 
The following figure shows two examples of nets. In the example. 
Net 1 consists of a driver pin (A) and a single load pin (B). Net 2 
consists of a driver pin (A) and multiple load pins (B. C. and D). 
The net contains a route-through at component COMP_l. 
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Net 1 



Figure 1-1 Net Example 

• A /wth is an ordered set of elements identifying a logic flow 
pathway through a circuit. A path can consist of a single net or a 
grouping of related nets and components. You can have multiple 
paths (consisting of nets and components) between the two pins. 
When a component is selected as part of a path, both the input 
pin to the component and the output pin are included in the path. 
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A path starts by including a dock-to-out delay at a synchronous 
element (flip flop, RAM, or latch) or from a pad. The path 
continues adding net delays and combinatorial delays. A path 
ends with a setup-to-clock delay at an asynchronous element (flip 
flop, RAM, or latch) or at a pad. The following figure shows a 
path through CLB1.CLB2, and CLB3. 


CUII CLB2 CLUJ 



Figure 1-2 Path Example 

• A bus is a grouping of related nets. For example, you can create a 
bus containing the nets DATA .00, DATA 01. DATA 02 and 
DATA 03—nets that supply data to RAM. 

• A BEL is a Basic ELement. BELs are the building blocks that make 
up a component (CLB or IOB)—function generators, flip-flops, 
carry logic, and RAMs. 

• A physical /micro is a logical function such as a counter that is 
created from a set of physical components for a specific device 
family. Physical macros, which are created using the FPGA 
Editor, are stored in files with the .nmc extension. In addition to 
components and nets, the file can also contain relative placement 
and/or routing information. A physical macro can be unplaced, 
partially placed, or fully placed, and it can also be unmuted, 
partially muled, or fully muted. Note that you cannot perform 
functional simulation of a physical macro. See the "Working with 
Physical Macros" chapter of the FPGA Eilitor Guide for 
information about physical macros. 
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Supported Platforms 


The Alliance 2.1i software supports several different operating 
systems, as shown in the following table. 


Platform Type 

Version Number 

Solaris 

Solaris 2.6 and 2.7 

HP Series 9l)(>0 

HP-UX 10.2 

Windows NT 

NT 4.0/95/98 

Japanese Windows 

NT/95/98 

Chinese Windows 

95/98 

Korean Windows 

95/98 
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Chapter 2 


Design Flow 


This chapter describes the process lor creating, implementing, 

verifying, and downloading designs lor FPGA and CPLD devices. 

For a complete description ol FPGAs and CPLDs, refer to The 

Programmable Logic Data Book. 

This chapter contains the following sections. 

• "Overview" 

• "Design Entry" 

• "Design Implementation" 

• "FPGA Editor" 

• "FPGA Design Techniques" 

• "Design Verification" 

Overview 

The design flow is a three-step process that consists of the following 

stages. 

• Design Entry — In this stage of the design flow, you create your 
design using a Xilinx-supported schematic editor, text-based 
entry (HDL), or both. 

• Design Implementation — By implementing to a specific Xilinx 
architecture, you convert the logical design file format, such as 
ED1F, that you created in the design entry stage into a physical 
file format. The physical information is contained in the NCD 
(Physical Description) file for FPGAs and the VM6 file for 
CPLDs. Then you create a bitstream file from these files and 
optionally program a PROM or EPROM for subsequent 
programming of your Xilinx device. 
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• Design Verification — Using a gate level simulator, the Xilinx 
XCheeker cable™, the Parallel Cable III, or MultiLINX cable, you 
ensure that your design meets your timing requirements and 
functions properly. See the Hardware User Guide for more 
information about Xilinx download cables and demonstration 
boards. 

Tire Xilinx design flow is shown in the following figure. 


XILINX DESIGN FLOW 



Milt 



Figure 2-1 Xilinx Design Flow Overview 

Tire full design flow is an iterative process of entering, implementing, 
and verifying your design until it is correct and complete. The Xilinx 
Development System allows quick design iterations through the 
design flow cycle. Since Xilinx devices permit unlimited 
reprogramming, you do not need to discard devices when debugging 
your design in-circuit. 
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Tine following table defines the terms used in the "Xilinx Design Flow 
Overview" figure. 

Table 2-1 Design Flow Terms 


Term 

Description 

Schematic entry 

Creates designs using graphic symbols 

Text-based entry 

Uses Hardware Description Language (HDL) or 
state machine editor 

Optimization 

Converts device-independent or behavioral logic 
descriptions to a form that can be efficiently 
implemented in a Xilinx device 

Mapping 

Represents a design's logic as resources of the 
Xilinx FPGA 

Placement 

Assigns design blocks created during mapping to 
specific locations in the FPGA 

Routing 

Assigns the interconnect paths in FPGAs 

Fitting 

Puts logic from your design into physical 
macrocell locations in the CPLD. Routing is 
performed automatically, and because of the 

UIM architecture, all designs are routable. 

Bitstream 

generation 

Converts a design into a bitstream that can be 
loaded into a Xilinx device. 

Back-annotation 

Associates implementation net delay 
information with the original nets found in the 
input design. 

Simulation 

Emulates a design's logic and timing using input 
stimuli 


Tine following figure shows the Xilinx software flow chart for 
designs. 
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Figure 2-2 Xilinx Software Design Flow 

Design Entry 

This section introduces the Xilinx design entry process. You can enter 
a design with a schematic editor or a text-based tool. For the Alliance 
software, these entry methods require Xilinx-supported third-party 
tools, which produce a design file in some third party netllst formats. 
For Foundation, you access the design entry tools from the 
Foundation Project Manager. 

Design entry begins with a design concept, expressed a.% a drawing or 
functional description. From the original design, a netllst is created, 
then synthesized and translated into a generic object file (NGO). This 
file Is fed into a program called NGDBuild, which produces a logical 
generic database file (NGD). 

The follow ing figure illustrates the design entry process. 
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Figure 2-3 Design Entry Flow 

Note: The NGD2XNF translation program is not supported by Xilinx 
2.11 software. 

The following sections describe the schematic and text-based design 
entry methods in detail. 

Schematic Entry Overview 

Schematic tools provide a graphic interface for design entry. You can 
use these tools to connect symbols representing the logic components 
in your design. You can build your design with individual gates, or 
you can combine gates to create functional blocks. This section 
lotuses on ways to enter functional blocks using library elements and 
LogiBLOX, the logic-design/synthesis tool. 

Library Elements 

The following section discusses pnmitives and macros, which are the 
"building blocks" of component libraries. 
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Xilinx libraries provide primitives as well as common high-level 
macro functions. Primitives are basic circuit elements, such as AND 
and OR gates. Each primitive has a unique library name, symbol, and 
description. Macros contain multiple library elements, which can 
include primitives and other macros. 

There are two types of macros you can use with Xilinx FPGAs. Soft 
macros, available for all FPGAs, have pre-defined functionality, but 
have flexible mapping, placement, and routing. Relationally placed 
macros (RPMs) have fixed mapping and relative placement. 
However, they are only available for XC-JOOOE/X, XC520D, Spartan 
series, and Virtex devices. 

Macros are not available for synthesis because synthesis tools liave 
their own module generators and do not require RPMs. If you wish to 
override the module generation, you can instantiate LogiBLOX or 
CORE Generator modules. For mast leading-edge synthesis tools, 
this does not offer an advantage unless it is for a module that cannot 
be inferred. 

Hierarchical Design 

Schematics usually contain hierarchy, which is important for the 
following reasons. 

• Helps you conceptualize your design 

• Adds structure to your design 

• Promotes easier design debugging 

• Makes it easier to combine different design entry methods 
(schematic, HDL, or state editor) for different parts of your 
design 

• Makes it easier to design incrementally. Incremental design 
consists of designing, implementing, and verifying individual 
sub-blocks of a design in stages 

• Reduces optimization time 

• Facilitates concurrent design, concurrent design is the process of 
dividing a design among a number of people who develop 
different parts of the design in parallel. 
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Hierarchical Names 

A specific hierarchical name identifies each library element, unique 
block, and instance you create. For example, the last three terms in 
the name 

/Acc/alu 1/mult 4/8count 3/4bit O/mux l/or2 

might refer to the 2-input OR gate in the first instance of a 
multiplexer in a 4-bit counter. 

Note: Xilinx strongly recommends that you name the components 
and nets in your design. In schematic editors, component names and 
net names are preserved and used by the FPGA Editor. The 
component names and net names are also used for back-annotation 
and appear in the debug and analysis tools. If you do not name your 
components and nets, the schematic editor automatically generates 
the names. For example, if left unnamed, the software might name 
the previous example as follows. 

/Slal23/$lb942/$lc23/Sld235/Slel21/$l<jl23/$ll>57 

It can be very difficult to analyze circuits with automatically 
generated names, since they only have meaning for Xilinx software. 

CORE Generator (FPGAs Only) 

The Xilinx CORE Generator design tool delivers parameterizable 
cores that are optimized for Xilinx FPGAs. The library includes cores 
as complex as DSP (Digital Signal Processing) filters and 
multiplexers, and as simple as delay elements. Refer to the COKE 
Generator System User Guide for details. 

LogiBLOX 

LogiBLOX is a tool which can generate a variety of variable-sized 
MSI- and LSI-level design building blocks such as adders, counters, 
decoders, and shift registers. These modules complement the Xilinx 
macro libraries, which contain simpler, fixed-size logic and gate 
functions. LogiBLOX also integrates these modules into your design. 
For further information, see the LogiBlX)X Guide. 

Note: LogiBLOX does not currently support the VTrtex and Spartan2 
families of FPGAs. 
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Text-Based Entry Overview (HDLs) 

Text based entry, such as modern HDLs and their associated 
simulators, are very powerful tools for integrated circuit designers. 

Note: State machines that are created by a State Editor are converted 
into HDL by Xilinx tools. 

A typical HDL supports a mixed-level description in which gate and 
netlist constructs are used with functional descriptions. This 
mixed-level capability enables you to describe system architectures at 
a very high level of abstraction, then incrementally refine a design's 
detailed gate-level implementation. 

HDL descriptions play an important role in modern design 
methodology for the following reasons. 

• You can verify design functionality early in the design process. A 
design written as an HDL description can be simulated 
immediately. Design simulation at this higher level, before 
implementation at the gate-level, allows you to evaluate 
architectural and design decisions. 

• An HDL description is more easily read and understood than a 
netlist or schematic description. HDL descriptions provide 
technology-independent documentation of a design and its 
functionality. Because the initial HDL design description is 
technology independent, you can use it again to generate the 
design in a different technology, without having to translate it 
from the original technology. 

• Large designs are easier to handle with HDL tools than schematic 
tools. 

Xilinx supports HDL tools for several third-party vendors such as 
Synopsys, Mentor, and Viewlogic. 

Controlling Implementation with Constraints 

Before you implement your design, you may want to constrain it 
within certain liming or placement parameters. You can specify 
mapping, block placement, and timing specifications during design 
entry. The following sections describe these methods. 
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Mapping (FPGAs Only) 

You can specify how a parficular block of logic is mapped info CLBs 
using a CLBMAP for XC3000 FPGAs; an FMAP or HMAP for 
XC4000E/X and Sparfan/XL FPGAs; or an FMAP or F5MAP for 
XC5000 FPGAs. These mapping symbols can be used in your 
schematic. However, if you overuse Ihese specifications, it may be 
harder to route your design. 

Block Placement 

Block placement can be constrained to a specific location, to one of 
multiple locations, or to a location range. Locations can be specified 
in the schematic, with synthesis tools, or in the User Constraint File 
(UCF). Poor block placement can adversely affect both the placement 
and the routing of a design. Typically, block placement defines I/O 
placement. For details about placement constraints, refer to the 
"Placement Constraints" section in the Libraries Guide. 

Timing Specifications 

You can specify timing requirements for paths in your design directly 
in your schematic. PAR (the Xilinx FPGA Place and Route program) 
uses these timing specifications to achieve optimum performance 
when placing and routing your design. See the Timing Analyzer Guide 
and the Constraints Editor Guide for a detailed explanation of timing 
specifications. Also refer to the "Using Timing Constraints" chapter 
in this manual. Development System Reference Guide. 

Testing Designs with Functional Simulation 

After you have entered your design, you can either simulate or 
implement your design. Functional simulation tests the logic in your 
design to determine if it works properly. You can save a lot of time 
during subsequent design steps if you perform functional simulation 
early in the design flow. For Alliance Software Series users, details on 
functional simulation can be found in the CAE-specific interface user 
guide provided with your Xilinx interface. For Foundation users, 
refer to the Foundation Series 2.1i User Guide. 
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Netlist Translation Program Overview 

Two netlist translation programs allow you lo read netlists inlo the 
Xilinx software tools. ED1F2NGD allows you to read an EDIF 2 0 0 
(Electronic Data Interchange Format) lile. XNF2NGD allows you to 
read an XNF (Xilinx Netlist Format). In the "Design Entry Flow" 
figure, these programs are contained within the "Netlist Translation" 
block. The NGDBuild program automatically invokes these programs 
as needed to convert your EDIF or XNF file to the required format for 
the Xilinx software tools. 

You can find detailed descriptions of the ED1F2NGD, XNF2NGD. 
and NGDBuild programs in later chapters in this book. Development 
System Reference Guide. 

Design Implementation 

Design implementation begins with the mapping or fitting of a 
logical design file to a specific device and is complete when the 
physical design lias been successfully routed and a bitstream has 
been generated. 

The following two figures give an overall view of the design 
implementation process for FPGAs and CPLDs. 
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Figure 2-4 Design Implementation Flow (FPGAs). 
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Figure 2-5 Design Implementation Flow (CPLDs) 
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FPGA Editor 

The FPGA edilor Is a graphical application used to display and 
configure your FPGA designs. You can perform the following 
functions with the FPGA Editor. 

• Place and route critical components before running automatic 
place and route tools on an entire design. 

• Modify placement and routing manually. The editor allows both 
automatic and manual component placement and routing. 

• Read from and write to the Physical Constraints File (PCF) to 
create and modify constraints. 

• Verify timing against constraints. 

• Create physical macros (nmc files) 

Editing operations performed within the FPGA Editor change the 
configuration of the design and also change the design database. 
Editing functions include selecting, adding and deleting objects, 
viewing and changing object attributes, copying components, 
swapping components and net pins, placing components, and 
routing. 

Tire FPGA Editor has its own set of commands, many of which can be 
customized to suit your work style. You can access these commands 
from the pull-down menus, user toolbar, command macros, hot keys 
and aliases, or by entering the commands on a command line within 
the FPGA Editor window. 

In addition to customizing commands, other FPGA Editor tools may 
also be tailored to your needs. For example, you can do the following. 

• Decide what commands are performed when the FPGA Editor 
window first opens 

• Choose the colors for different objects (for example, components) 
and areas (for example, the push button panel or command area) 
in the FPGA Editor window 

• Use command macros and hot keys 

For more information, see the FPGA Edilor Guide. 
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FPGA Design Techniques 

Tine Xilinx FPGA architecture is best suited for synchronous design. 
Strict synchronous design ensures that all registers an* driven from 
the same time base with no clock skew. The following sections outline 
several tips lor producing high-performance synchronous designs. 

Design Size and Performance 

Information about design size and performance can help you to 
optimize your design. When you place and route your design, the 
resulting report files list the number of CLBs, IOBs and other device 
resources available. A first pass estimate can be obtained by 
processing the design through the map program. 

If you want to determine the design size and performance without 
running automatic implementation software, you can quickly obtain 
an estimate from a rough calculation based on the Xilinx FPGA 
architecture. See The ProgramnuiNe Logic Data Book for more 
information on all Xilinx FPGA architectures. 

Global Clock Distribution 

Xilinx clock networks guarantee extremely small clock skew values. 
Tine following table lists the resources available for several Xilinx 
FPGA families. 
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Table 2-2 Global Clock Resources 


FPGA Family 

Resource 

Number 

Destination Pins 

XC3000A/L 




XC3100 

XC3100A/L 

GCLK 

1 

Clock 

XC4000E/L 

BUFGP 

4 

K. IK 


BUFGS 

4 

K. IK 

XC4000EX/XL 

BUFG 

1 

K. IK 


BUFGLS 

8 

K. IK 


BUFGE 

8 

K. IK 


BUFFCLK 

4 

K. IK 

XC5200 

BUFG 

4 

Clock or Control 

Spartan/XL 

BUFGP 

BUFGS 

4 

Clock 

Virtex, Spartan2 

BUFG 

4 

Clock 


Note: For global clock information about the XC4000XV and 
XC4000XLA device families, refer to the Xilinx website at http:// 
www.xilinx.com/products/products.htm 

XC4000 BUFC.P and BUFGS also connect to control pin and logic 
inputs: however, for designs requiring extensive routing, there might 
be extra delay on these loads. 

Other Synchronous Design Considerations 

Other considerations for achieving a synchronous design include the 
following. 

• Use clock enables instead of gated clocks to control the latching 
of data into registers. See the "Gated Clock" figure and the 
"Synchronous Design Using Data Feedback" figure. 

• If your design has more clocks than the number of global clock 
distribution networks, try to redesign to reduce the number of 
clocks. Otherwise, put the clocks that have the lowest fanout onto 
normally routed nets, and specify a low .Vl.AXSKEW rating. 
Remember that a clock net routed through a normal net lias skew. 
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Data Feedback and Clock Enable 

Tlie timing diagram indicates that this implementation can lead to 
clock glitches; this can cause the flip-flop to clock at the wrong time. 

a) Gated Clock 


Clock 

Enable 

b) Corresponding Timing Diagram 


Enable 

Clock 


=D- 


Clock 

Enable 



Clock n 

Enable I 


Output 



X2082 


Figure 2-6 Gated Clock 

Tine "Synchronous Design Using Data Feedback" figure shows a 
synchronous alternative to the gated clock using a data path. The flip- 
flop is clocked at every clock cycle and the data path is controlled by 
an enable. When the enable is Low. the multiplexer feeds the output 
of the register back on itself. When the enable is High, new data is fed 
to the flip-flop and the register changes its state. This circuit 
guarantees a minimum clock pulse width and it does not add skew to 
the clock. The XC4000. XC5200, Spartan2. and Virtex flip-flops have a 
built-in clock-enable (CE). 
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a) Using a Feedback Path 
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b) Corresponding Timing Diagram 
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Figure 2-7 Synchronous Design Using Data Feedback 

Counters 

Cascading several small counters to create a larger counter is similar 
to a gated clock. For example, if two 8-bit counters are connected, the 
TC (terminal counter) of the first counter is a large AND function 
gating the second clock input. Using the CE input, you can create a 
synchronous design as shown in the following figure. In this case, the 
TC (terminal counter) of the first stage is connected directly to the CE 
of the second stage. 
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a) 16-bit counter with TC connected to the clock. 



b) 16-bit counter with TC connected to the clock-enable. 
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n 

> 


X2093 

Figure 2-8 Two 8-Bit Counters Connected to Create a 16-Bit 
Counter 

Design Verification 

This section introduces design verification, which is the process of 
testing the functionality and performance of your design. The Xilinx 
Development System supports three complementary methods for 
design verification: simulation, static timing analysis, and in-circuit 
verification. 

Overview 

Design verification procedures should occur throughout your design 
process, as illustrated in the following figure. 


2-fS 


Xilinx Development System 




Design Flow 



Figure 2-9 Three Verification Methods of the Design Flow 
(FPGAs) 
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Figure 2-10 Three Verilicalion Methods ot the Design Flow 
(CPLDs) 

You can verity Xilinx designs in three different ways. 

• Simulation 

• Static timing 

• In-circuit verification 

Each verification type uses different design tools; see the following 
figure for a description. 
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Verilicalion Tools 
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Figure 2-11 Verilicalion Tools 

Pre-Simulation Translation 

Before simulation occun>, the physical design information must be 
translated and distributed back to the logical design. For FPGAs, this 
back-annotation process is done with a program called NGDAnno. 
For CPLDs, back-annotation is perfoimed with the TSIM Timing 
Simulator. These programs create a database for the netlist writers, 
which translate the back-annotated information into a netlist format 
that can be used for simulation. The back-annotation flows are shown 
in the following figures. 
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Figure 2-12 Back-Annotation (FPGAs Only) 
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Figure 2-13 Back-Annotalion (CPLDs Only) 

Note: The NGD2XNF program (and the XNF output File lorinat) are 
not supported In tlie 2 . 1 i software. 

NGDAnno (FPGA’s Only) 

NGDAnno is a program that distributes delays, setup and hold lime, 
and pulse widths found in tire physical NCD design file back to the 
logical NGD file 

NGDAnno merges mapping information from the NGM File with 
placement, routing, and timing information from the NCD file. This 
data is combined into a generic annotated (NGA) file. The NGA File is 
input to the appropriate netlist writer (NGD2EDIF. NGD2VER, or 
NGD2VHDL) which then converts the binary Xilmx database format 
back to an ASCII netlist. 

Note: Use caution when making changes to the functional behavior 
of your design. For example, if you make logical changes to an NCD 
design from within tire FPGA Editor, the graphical design editor, 
NGDAnno will be unable to correlate the changed objects in the 
physical design with the objects in the logical design. 
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It will then recreate the entire NGA design from the N'CD and issue a 
warning indicating that the NCD is out of sync with the NGM. 

An NCD file is input to the NGDAnno program. The NCD file can be 
a mapped-only design, or a partial or fully placed and routed design. 
An NGM file which is created by the mapper is an optional source of 
input. 

The output of NGDAnno is an NGA file, which is a back-annotated 
NGD file. For details on NGDAnno mfer to the "NGDAnno" chapter. 

CPLD command 

Tine CPLD command automatically generates the NGA file unless the 
command is run with the notsim option. For a description of the 
CPLD command and its options, refer to the "Fitter Command and 
Option Summary" appendix in the CPLD Synthesis Design Guide. 

Netlist Writers 

Netlist writers take the output of NGDAnno or the CPLD command 
and create a simulation netlist in the specified format. An NGD or 
NGA file is input to each of the netlist writers. The NGD file is a 
logical design file containing primitive components, while the NGA 
file is a back-annotated logical design file. Following is a list of the 
supported netlist writers with descriptions of their input and output 
files. 

• NGD2ED1F — takas an NGD or NGA file and translates it into an 
ED1F netlist. 

Output from the NGD2ED1F program is an EDN file, a netlist in 
ED1F foimat. Tine default EDN file produced by NGD2EDIF is 
generic. If you want to produce ED1F targeted to Mentor 
Graphics or Viewlogic, you must include the -v (vendor) option. 

• NGD2VER— translates an NGD or NGA file into a Verikig netlist 
(V) file. If the input is an NGA file, NGD2VER will also generate 
an SDF (Standard Delay Format) file. 

Tine resulting V and SDF files will have the same root name as the 
NGD or NGA file unlass you specify otherwise. 
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Tine SDF file contains timing information intended solely for use 
with the Verilog file which was generated from the same NGA 
file. Do not attempt to use the SDF file in conjunction with the 
original Verilog netlist design or the product of another netlist 
writer. 

• NGD2VHDL — translates an NC.D or NGA file into a VHDL 
netlist (VHD). If the input file is an NGA file. NGD2VHDL will 
also generate an SDF (Standard Delay Format) file. The VHD and 
SDF files will have a tim sim root name by default. To change the 
root name of your files, go to the Simulation Data Options dialog 
box and select the VHDL/Verilog tab. 

For more information on the Netlist Writers or NGDAnno, refer 
to later chapters in this manual. 

Invoking Netlist Writer Programs 

You can invoke any of the supported netlist writer programs (for 
example, NGD2VER. NGD2F.D1F) from the UNIX or DOS command 
line. Most of the programs can be invoked from the Design Manager 
for Alliance or the Project Manager for Foundation. 

Select the NGD2 and netlist writer commands as follows. 

1. If you are an Alliance user, proceed as follows: 

a) Open the Xilinx Design Manager. 

b) Select Design -» Implement. 

c) Select a part and then click the Options button. 

d) Proceed to Step 3. 

2. If you are a Foundation User, proceed as follows: 

a) Open the Project Manager. 

b) Click Implementation -* Implementation Options. 

c) Proceed to Step 3. 

3. Select a netlist writer program from the Simulation drop-down 
list box. 
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Additional Translation Options 

In addition to back-annotating a fully routed design, you can also 
back-annotate a translated but unmapped design and a mapped but 
unrouted design for FPGAs. You can also create an output netlist to 
allow simulation of the design at the different stages of development 
in the Xilinx environment. 

Pre-implementation Circuit Verification 

For example, if you want to verify that the circuit logic is correct before 
you implement the design, you can use the data in a non- 
implemented NGD design as input to the netlist writers NGD2EDIF. 
NGD2VER, or NGD2VHDL. You then run a simulation program on 
the resulting netlist. 

Simulating Designs with Block Delays (FPGAs Only) 

To simulate a design that contains only IOB and CLB block delays, 
you can take the .NCD file produced by MAP and then run 
NGDAnno. Afterwards, run the appropriate netlist writer to generate 
a simulatable netlist. 

Block delays are generally 50% of your path delay. Simulating with 
block delays is an imprecise method of determining whether your 
timing will be met before you actually place and route. (However, 
this simulation type is less time consuming than performing a full 
timing simulation.) The simulation process is shown in the "Back- 
Annotation (FPGAs Only)" figure. 

Schematic-Based Simulation 

Design simulation involves testing your design using software 
models. It is mast effective when testing the functionality of your 
design and its performance under worst-case conditions. You can 
easily probe internal nodes to check your circuit's behavior, and then 
use these results to make changes in your schematic. 

Simulation is performed using third-party tools that are linked to the 
Xilinx Development System. Use the various CAE-specific interface 
user guides, which cover the commands and features of the Xilinx- 
supported simulators, as your primary reference. 
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The software models provided for your simulation tools are designed 
to perform detailed characterization of your design. You can perform 
functional or timing simulation, as described in the following 
sections. 

Functional Simulation 

Functional simulation determines if the logic in your design is correct 
before you implement it in a device. 

Functional simulation can take place at the earliest stages of the 
design flow. Since timing information for the implemented design is 
not available at this stage, the simulator tests the logic in the design 
using unit delays. 

Note: It is usually faster and easier to correct design errors if you 
perform functional simulation early in the design flow. 

Tine verification methods figures show the design flows for 
integrated and non-integrated simulation tools. Integrated tools such 
as Mentor or Viewlogic contain a built-in interface which links the 
simulator and a schematic editor, allowing the tools to use the same 
netlist. You can move directly from entry to simulation when using a 
set of integrated tools. 

Functional simulation in schematic-based tools is usually performed 
immediately after Design Entry in the capture environment. The 
schematic capture tool requires a Xilinx Unified Library and the 
simulator requires a library if the tools are not integrated. Most of the 
schematic-based tools will require translation from their native 
database to XNF or ED1F for implementation. The return path from 
implementation is usually XNF or EDIF with certain exceptions 
where a schematic tool is tied to an HDL simulator. 

Timing Simulation 

Timing simulation verifies that your design runs at the desired speed 
for your device under worst-case conditions. This process is 
performed after your design is mapped, and placed and routed for 
FPGAs or fitted for CPLDs. At this time, all design delays are known. 

Timing simulation is valuable because it can verify timing 
relationships and deteimine the critical paths for the design under 
worst-case conditions. It can also determine whether or not the 
design contains set-up or hold violations. 


Development System Reference Guide 


2-27 




Devetopmenl System Reference Guide 


To input timing information into your design, you must convert the 
routed NCD file into an NGA file. The resulting NGA file can then be 
translated by NGD2EDIF, NGD2VER, or XNF2NCD. These netlist 
writers create suitable formats for various simulators. 

Note: Naming the nets during your design entry is very important 
for both functional and liming simulation. This allows you to find the 
nets in the simulations more easily than looking for a machine¬ 
generated name. 

HDL-Based Simulation 

Xilinx supports functional and timing simulation of HDL designs at 
the following three points in the HDL design flow as shown in the 
following figure. 



Figure 2-14 Three Simulation Points for HDL Designs 

• Register Transfer Level (RTL simulation which may include the 
following 

• Instantiated UN1SIM library componenLs 

• LogiBLOX modules 

• LogiCORE models 
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• Post-synthesis functional simulation with one of the following. 

• Cate-level UNISIM library components 

• Cate-level pre-route S1MPRIM library components 

• Post-implementation back-annotated timing simulation with the 
following. 

• SIMPRIM library components 

• Standard Delay Format (SDF) file 

The three primary simulation points can be expanded to allow for 
two additional post-synthesis simulations, as shown in the following 
table. These two additional points can be used when the synthesis 
tool either cannot write VHDL or Verilog. or if the netlist is not in 
terms of UNISIM components. 

Table 2-3 Five Simulation Points in HDL Design Flow 


Simulation 

UNISIM 

LogiBLOX 

Models 

SIMPRIM 

SDF 

1. 

RTL 

X 

X 



191 

Post-Synthesis 

X 

X 



i 

Functional Post-NCDBuild 
(Optional) 



X 


4. 

Functional Post-MAP 
(Optional) 



X 

X 

5. 

Post-Route Timing 



X 

X 


These simulation points are described in various sections of the 
"Simulating Your Design" chapter of the Synthesis and Sinuilition 
Design Guide. These sections include the following: 


• "Functional Simulation" 

• "Timing Simulation" 

The libraries requited to support the simulation flows are described 
in detail in the "Using \'HDL/Verilog Libraries and Models" section. 
Tlie new flows and libraries now support closer functional 
equivalence of initialization behavior between functional and timing 
simulations. This is due to the addition of new methodologies and 
library celLs to simulate CSR/C.TS behavior. 
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11 is important to address the built-in reset circuitry behavior in your 
designs starting with the fiist simulation to ensure that the 
simulations agree at the three primary points. 

If you do not simulate GSR (Global Set/Reset) behavior prior to 
synthesis and place and route, your RTL and possibly post-synthesis 
simulations will not initialize to the same state as your post-route 
timing simulation. As a result, your various design descriptions are 
not functionally equivalent and your simulation results will not 
match. In addition to the behavioral representation for GSR, you need 
to add a Xilinx implementation directive. This directive is used to 
specify to the place and route tools to use the special purpose GSR net 
that is pre-routed on the chip, and not to use the local asynchronous 
set/reset pins. Some synthesis tools can identify, from the behavioral 
description, the GSR net, and will place the STARTUP module on the 
net to direct the implementation tools to use the global network. 
However, other synthesis tools interpret behavioral descriptions 
literally, and will introduce additional logic into your design to 
implement a function. Without specific instructions to use device 
global networks, the Xilinx implementation tools will use general 
purpose logic and interconnect resources to redundantly build 
functions already provided by the silicon. 

Even if GSR behavior is not described, the actual chip initializes 
during configuration, and the post-route netlist will have this net that 
must be driven during simulation. The "Simulating Global Signals" 
section of the Synl/irsis and Simulation Design Guide includes the 
methodology to describe this behavior, as well as the GTS (Global 
Tristate) behavior for output buffers. 

For a complete discussion of GSR and GTS. refer the following 
sections in the "Simulating Your Design” chapter of the Synthesis and 
Simulation Design Guide. 

• "Adapting Schematic Global Signal Methodology for Y'HDL” 

• "Setting VHDL Global Set/Reset Emulation in Functional Simu¬ 
lation" 

• "Setting Verilog Global Set/Reset” 

• "Setting Verilog Global Tristate (XC4000, Spartan, and XC3200 
Outputs Only)" 
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Xilinx VHDL simulation supports the VITAL standard. This standard 
allows you to simulate with any VlTAL-compliant simulator, 
including MTl/Mentori' ModelSim, Synopsys VSS. and Active- 
VHDL. 

Built-in Verilog support allows you to simulate with the Cadence 
Verilog-XL and other compatible simulators. Xilinx HDL simulation 
supports all current Xilinx FPC.A and CPLD devices. Refer to the 
"Using VHDL/Verilog Libraries and Models" section for the list of 
supported VHDL and Verilog standards. 

For information about CPLD HDL simulation refer to the 
"Simulating Your Design" chapter of the CPU) Synthesis Design 
Guide. 

Static Timing Analysis With TRACE (FPGAs Only) 

Static timing analysis is best for quick timing checks of a design after 
placement and routing is complete. 

TRACE (Timing Reporter and Circuit Evaluator) Ls a Xilinx 
application program designed to provide static timing analysis and 
can be used to evaluate how well the place and route tools have met 
any input timing constraints. 

By using TRACE, you can quickly check for timing problems in your 
FPGA design. You can also use TRACE to determine path delays in 
your design. 

TRACE performs two major functions. 

• Timing verification — the process of verifying that the design 
meets your timing constraints. 

• Reporting — the process of enumerating input constraint 
violations and placing them into an accessible file. TRACE can be 
run on partially or completely placed and routed designs. The 
timing information reported issued by TRACE depends on the 
completeness of the placement and routing of the input design. 

Within the Design Manager. TRACE is run using the Timing 
Analyzer. See the Timing Analyzer Guide for details. 
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In-Circuit Verification 

As a final lest, you can verify how your design performs in the target 
application. In-circuit verification tests the circuit under typical 
operating conditions. Because you can program your Xilinx devices 
repeated 1 )', you can easily load different iterations of your design into 
your device and test it in-circuit. To verify your design in-circuit, 
download your design bitstream into a device with the Xilinx 
XChecker Cable, Parallel Cable III, or MultiLINX cable. 

Note: For information about Xilinx cables and hardware, see the 
Hardware User Guide. 

Design Rule Checker (FPGAs Only) 

Before generating the final bitstream, it is important to use the DRC 
option in BitGen to evaluate the NCD file for problems that could 
prevent the design from functioning properly. DRC will be invoked 
automatically unless you use the -d option. 

Xilinx Design Download Cables 

Xilinx provides the Parallel Cable Ill. XChecker cable, or MultiLINX 
cable, depending on which development system you are using. To 
download your design, you must create a configuration bitstream. 

For FPGAs, you can use the XChecker or MultiLINX cable to read 
back and verify configuration data. Detailed cable connection and 
daisy-chain information is provided in the Hardware Debugger Guide. 

Note: The Xilinx Parallel Cable III can be used for FPGA and CPLD 
design download and readback. but it does not have a design 
verification function. 

With the XChecker cable, you can use the Hardware Debugger Pick 
function to take snapshots of the circuit at specific clock cycles. You 
can obtain these snapshots by performing serial readback of the 
nodes during in-circuit operation. With the Hardware Debugger 
software, you can speed up your analysis by limiting the readback 
bitstream to only those nodes and clock cycles in which you have 
interest. 

You can also use the XChecker cable to probe your design after you 
download it. Probing internal nodes allows you to pinpoint the 
location of any design problems. 
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Use the XChecker table when you do nol wanl to specify additional 
IOBs and touting resources on your Xilinx FPGA for probing. This 
allows you to decide how you want to probe after you have 
downloaded your design. 

Tire MuitiLINX Cable is compatible in supporting Readbaek it Verify 
for all the FPGAs supported by the XChecker cable. In addition to the 
supporting legacy devices, the MuitiLINX Cable supports the devices 
that were not supported by the XChecker cable. Supported devices 
include those devices in the 4000E, 4000XL, and Spar tan families 
whose bit file size is more than 256K bits. The MuitiLINX Cable also 
supports readbaek & verify for the new Vi ilex family. 

Note: Debug is not available with the MuitiLINX Cable in 2.1i. 
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PARTGEN _ 

This program is compatible with the following families. 

• XC3000A' U /L ,U 

• XCSIOGA'^/L 1 * 1 

• XC4000E T * , /L™ 

• XC4000EX ,U /XL™/XV' , /XLA ,M 

• XC5200™ 

• Spartan'* 1 

• SparlanXL 1 * 1 

• Virtex™ 

• XC9500™ 

• XCOSOOXL 1 * 

This chapter describes PARTGEN. The chapter contains the following 
sections. 

• PARTGEN" 

• "PARTGEN Syntax" 

• "PARTGEN Files" 

• "PARTGEN Options" 

• "Partlist.xct File Contents" 
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PARTGEN 

Tine PARTGEN command displays various levels of information 
about installed Xilinx devices and families depending on which 
options are selected. 

PARTGEN Syntax 

Following is the syntax for PARTGEN. 
partgen |epfions| 

Options can be any number of the options listed in the "PARTGEN 
Options" section. They do not need to be listed in any particular 
order. Separate multiple options with spaces. 

PARTGEN Files 

Tine following subsections describe the input and output files for 
PARTGEN. 

Input Files 

PARTGEN does not have any user input files. 

Output Files 

PARTGEN creates the output file, partlist.xct. This output file is only 
generated when using the -p and -v options. See the "Partlist.xct File 
Contents" section for a detailed description. 

Tire -p and -v options also generate package files. These files correlate 
lOBs with output pin names. For example, the command partgen - 
p xc4003 generates the package files: 4003cbl00.pkg, 4003pc84.pkg. 
4003pql00.pkg. 4003cql(X).pkg, and 4003pgl20.pkg. Following Ls a 
portion of the package file for the xc4003cbl00. 

package 4003cbl00 
pin PAD1 P99 
pin PAD2 P98 
pin PAD3 P97 
pin PAD4 P96 
pin PADS P9S 
pin PAD6 P94 
pin PAD? P93 
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pin PADS P92 
pin PAD9 P91 


PARTGEN Options 

Following is a description of the command line options and how they 
affect the behavior of PARTGEN. With no options, PARTGEN prints 
out the following usage massage. 

part.gen - Print out the list of supported parts for the installed 
architectures. 

print a list of devices, packages, and speeds that, are installed, 
-arch: print a list of devices, packages, and speeds for the specified 
architecture <if it is installed). 

-p: generate a part list.xct. If no architecture, device or part 

is specified, print all nation to parlist.xct. Otherwise generate 

data only for the foully nenbers specified. 

-v: generate a verbose partiist.xct. If no architecture, device, or device 
package is specified, print all infcrnation to parlist.xct. Otherwise 
generate data only for the family members specified. 

NOTE: -v and -p options are mutually exclusive. 

-arch (Print Information for Specified architecture) 

-arch architecturejtame 

The -arch option prints a list of devices, packages, and speeds for a 
specified architecture that has been installed. 

Valid entries for architecturejmme ate as follows: 

• XC3000 

• XC310O 

• XC4000 

• XC4000EX 

• XC4000XL/ 

• XC4000XV 

• XC4000XLA 
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• XC5200 

• Spartan 

• SpartanXL 

• Virtex 

• XC9500 

• XC9500XL 

-i (Print a List of Devices, Packages, and Speeds) 

Tine -i option prints out a list of devices, packages, and speeds that 
have been installed. 

-p (Creates Package file and Partlist.xct File) 

-p name 

Tine -p option generates a partlist.xct file for the specified name and 
also creates package files. All files are placed in the current working 
directory. Valid name entries include architectures, devices, and 
parts. Following are example command line entries of each type. 

-p xc4000 (Architecture) 

-p xc4003 (Device) 

-p 4003CB100 (Part) 

If no architecture, device, or PART is specified with the -p option, 
detailed information for every installed device is submitted to the 
partlist.xct file. 

Tine -p option generates more detailed information than the -arch 
options but less infomnation that the -v option. The -p and -v options 
are mutually exclusive, that is, you can specify one or the other but 
not both. 

Following is an example display for the command pactgen -p 
4036EXHQ240. 

patC400Q 4036EXhq240 NA.dio 4036hq240.pkg \ 

TDI=PAD284 7CK=PAD283 TM3=PAD268 \ 

NCLBROKS=36 NCLBCOLS-36 3TYLE=XC400QEX \ 

EDGE.DECODERS=4 \ 
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IH_Fr_P£R_IC3-l OUT_FF_PER_IOB=l \ 

JiFSAME3= 1775 HEX TSPERFSAME=<3 62 

For a description of the entries in the paitlist.xct file, see the 
"Partlist.xct File Contents" section. 

-v (Creates Packages and Partlist.xct File) 

-v name 

The -v option generates a partlist.xct file for the specified name and 
also creates packages files. Valid name entries include architectures, 
devices, parts. Following are example command line entries of each 

l yp e * 

part gen -v xc4000 (Architecture) 

partgen -v xc4003 (Device) 

partgen -v 4003CB100 (Part) 

If no architecture. device, or part is specified with the -v option, 
information for every installed device Ls submitted to the pai tlist-xct 
file. 

The -v option generates more detailed information than the -p option. 
The -p and -v options are mutually exclusive, that is, you can specify 
one or the other but not both. 

Following is an example display for the command partgen -v 
4036EXHQ240. 

part4000 4036EXhq240 NA.die 4036hq240.pkg \ 

TD1=PAD284 TCK=PAD283 7M3-PAD2C& \ 

NCLBROM3=36 NCLBCOLS=36 S7TLE=XC4000EX \ 

EDGE_DECODER5=4 \ 

IN_FF_PER_ICB-1 OUT_FF_PER_IOB=l \ 

NPADS_PER_RCK=2 HPADS_PER_COL=2 \ 

NFRAMES=1775 >JBIT3PERFRAME=462 \ 

N1OBS=208 HBICBS=193 \ 

SLICES_PER_CLB-1 \ 

FF3_PER_SLICE-2 \ 
latches_per_sl:ce=true \ 

LU7_NAMF-F LUT_SIZE=4 LUT_>JAME-G LU7_SIZE=4 \ 

LU7_NAME-H LUT_SIZE=3 \NUM_GLOBAL_BUFFER3-8 \ 

BUFG1S_MHK-PAD1 BUFGLS_NNE=PAD71 BUFGLS_SSX-PAD2I6 
BUFGLS_SSE-PAD145 BUFGLS_WNW=PAD288 BUFGLS_ENE=PAD73 BUFGLS_KSX-PAD217 
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BUFGLS_ESE=PAD 1 *3 3 \ 

NUM_7BUFS_PER_ROW= 7 6\ 

NUM_CARRY_ELEMEt*r3_PER_SLICE=2\ 

SPEEDGRADE=-2 LUTDELAY=15Q0 IOB_IN_DELAY=1710 ICB_CX;T_DELAY=7310 \ 
SPEEDGRADE--3 LUTDELAY-1700 IOB_IN_DELAY=1610 ICB_CX;T_DELAY=7 820 \ 
SPEEDGRADE--4 U7TBELAY=2040 IOS_IN_DELAY=2170lOB_OUT_CELAY=9380 

For a description of the entries in the partlist.xct file, see the 
"Partlist.xct File Contents 4 ’ section. 

Partlist.xct File Contents 

The partlist.xct tile contains detailed information about architectures 
and devices. 

Tine partlist.xct tile is a series ot part entries. There is one entry for 
every part supported in the installed software. The following 
subsections describe the information contained in the partlist.xct file. 

Header 

Tine first part is a header for the entry. Tine fomnat ot the entry looks 
like the following. 

pare arthilalttrefamily partname ditname padMgefilenttme 
Following Ls an example for the XC4Q36EXhq240. 
part.4000 403tEXhq240 MA.dio 4036hq240.pkg 

Device Attributes 

Tine header is followed by a list of device attributes. Not all attributes 
are applicable to all devices. 

• BSC AN pin mappings: TDK=PAD# TDI=PAD# TMS=PAD# 

• CLB row and column sizes: NCLBROWS=# NCLBCOLS=# 

• Sub-family designation: STYLE=sufc family 
(For example. STYLE = XC4000EX) 

• Width of the edge decoder (found in the XC5200 and XC4000 
families): EDGE DECODER^# 

• Input registers: 1N_FF. PER IOB=# 

• Output registers: OUT .FF PER IOB=* 
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• Number of pads per row and per column: NPAD5 PER ROW=# 
NPADS PER COL=# 

• BiLslreann information: 

• Number of frames: NFRAMES=# 

• Number bits/frame. NBFTSPERFRAME=# 

Tine preceding bulleted items display for both the -p and -v options. 
Tine following bulleted items only display when using the -v option. 

• Number of IOBS in device: NIOBS=# 

• Number of bonded IOBS: NBIOBS=# 

• Slices per CLB: SLICES PER CLB=# 

For slice-based architectures; for example, virtex. 

(For non-slice based architectures, assume one slice per CLB) 

• Flip-flops for each slice: FFS PER SLICE=# 

• Latches for each slice: LATCHES PER SL1CE=|TRUE I FALSE' 

• LUTs in a slice: LUT_NAME=Mflwie LUT_S1ZE=# 

• Number of global buffers: NUM GLOBAL BUFFERS^# 

(The number of places where a buffer can drive a global clock 
combination) 

• External Clock IOB pins: 

• For the XC3000 family: TCLKIOB=PAD# BCLK!OB=PAD# 

• For the XC4000/XC4000E family: 

BUFGP_TL=PAD#, BUFC.P BL=PAD», 

BUFG.P BR=PAD#, BUFGP TR=PADt>, 

BUFGS TL=PAD#, BUFGS BL=PAD#, 

BUFGS BR=PAD», BUFGS _TR=PAD# 

• For the XC4000EX/XC4000XL/XC4000XLA/XC4000XV/ 
SpartanXL families: 

BUFGLS _NNW=PAD#, 

BUFGLS WNW=PAD#. 

BUFGLS _NNE=PAD#, 

BUFGLS ENE=PAD#. 

BUFGLS SSVV=PAD#. 
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BUFC.LS WSW=PAD, 

BUFGLS 5SE=PAD#, 

BUFC.LS ESE=PAD# 

• For the XC5200 family: 

BUFG TL=PAD@, BUFG_TR=PAD» r 
BUFG BL=PADf, BUFC. BR=PAD# 

• For Ihe Virtex families: 

GCLKBUFD=PAD«. GCLKBUFl=PAOf, 

C,CLKBUF2=PAD#. GCLKBUF3=PAD» 

• Oscillator pins for the XC3000 family: 
OSCIOBl=PAD#.OSCIOB2=PAD# 

• Block RAM. 

NUM BLK RAMS=# BLK RAM SIZE=#X# 

(for example, NUM BLK RAMS-10 BLK RAM SIZE=40%X1) 

• Select RAM: 

NUM SEL RAMS=# SEL RAM ,SIZE=#X# 

• Select Dual Port RAM: 

SEL DP RAM=|TRUE I FALSE} 

This field indicates whether the select RAM can be used as a dual 
port ram. The assumption is that the number of addressable 
elements is reduced by half, that is, the size of the select RAM in 
Dual Port Mode is half that indicated by SEL RAM SIZE. 

• Speed grade information: SPEEDGRADE=# 

• Typical delay across a LUT for each speed grade: LUTDELAY=# 

• Typical IOB input delay: IOB IN DELAY:# 

• Typical IOB output delay: IOB OUT DELAY:# 

• Maximum LUT constructed in a slice: 

MAX. LUT. PER_SL1CE=# 

(From all the LUTs in the slice) 

• Max LUT constructed in a CLB: MAX LUT PER CLB=# 
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(This field describes how wide a LUT can be conslrucled in the 
CLB from the available LUTs in the slice.) 

• Number of internal tristate buffers in a device: NUM TBUFFS=# 
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This program is compatible with the following families. 

• XC3000A 

• XC3100A 

• XC4000E 

• XC4000EX 

• XC5200 

• Spartan 

• Sparlan2 

• SpartanXL 

• Virtex 

• XC9500 

• XC9500XL 

Tliis chapter describes the NGDBuild program. The chapter contains 
the following sections. 

• "NGDBuild" 

• "NGDBuild Syntax" 

• "NGDBuild Files" 

• "NGDBuild Options" 

• "Netlister Launcher" 

• "File Names and Locations" 
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NGDBuild 

NGDBuild performs all the steps necessary to read a net list file in 
XNF or EDIF formal and create an NGD file describing the logical 
design (a logical design is in terms of logic elements such as AND 
gales, OR gales, decoders, flip-flops, and RAMs). The NGD file 
tesulling from an NGDBuild run contains bolh a logical description 
of the design reduced to Xilinx NGD (Native Generic Database) prim¬ 
itives and a description in terms of the original hierarchy expressed 
in the input netlist. The output NGD file can be mapped to the 
desired device family. 

The following figure Ls a simplified drawing of the design flow 
through NGDBuild. NGDBuild invokes other programs and 
generates intermediate (NGO) files that an? not shown in the 
drawing. For a complete description of how NGDBuild works, see 
the "EDIF2NGD, XNF2NGD. and NGDBuild" appendix. 



Figure 4-1 NGDBuild Design Row 
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Converting a Netlist to an NGD File 

NGDBuild performs the following steps to convert a netlist to an 
NGD file (see the preceding figure). The netlist readers incorporate 
NCF files associated with each netlist. NCF files contain timing and 
layout constraints for each module. 

Note: This procedure, the Netlister Launcher, and the netlist reader 
programs are described in more detail in the "EDIF2NGD, 
XNF2NGD. and NGDBuild" appendix. 

1. Reads the source netlist. 

NGDBuild invokes the Netlister Launcher which determines the 
type of the input netlist and starts the appropriate netlist reader 
program. 

2. Reduces all components in the design to NGD primitives. 

NGDBuild merges components that reference other files. 
NGDBuild also finds the appropriate system library components, 
physical macros (NMC files) and behavioral models. 

3. Checks the design by running a Logical DRC (Design Rule 
Check) on the converted design. 

Tile Logical DRC is a series of tests on the logical design. It is 
described in "Tlie Logical Design Rule Check" chapter. 

4. Writes an NGD file as output. 

NGDBuild Syntax 

Tine following command reads the design into the Xilinx 
Development system and converts it to an NGD file. 

ngdbuild design, name [ii£<f file (. ngd|| 

Options can be any number of the NGDBuild options listed in the 
"NGDBuild Options" section. They do not need to be listed in any 
particular order. Separate multiple options with spaces. 

Design /tame is the top-level name of the design file you want to 
proeess.To ensure the design processes correctly, specify a file 
extension for the input file. Use one of the legal file extensions 
specified in the "Input Files” section. Using an incorrect or 
nonexistent file extension causes NGDBuild to fail without creating 
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an NGD file. It you use an incorrect file extension, NGDBuild may 

issue an "unexpanded" error. 

Ngd file |. ngd] is the output file in NGD format. The output tile 

name, its extension, and its location are determined as follows. 

• If you do not specify an output file name, the output file has the 
same name as the input file, with an .ngd extension. 

• If you specify an output file name with no extension, NGDBuild 
appends the .ngd extension to the file name. 

• If you specify a file name with an extension other than .ngd, you 
get an error message and NGDBuild does not run. 

• If the output file already exists, it is overwritten with the new file. 

NGDBuild Files 

This section describes the NGDBuild input and output files. 

Input Files 

Tine input files to NGDBuild aie the following. 

• Design file—The input design can be an XNF or ED1F 2 0 0 
netlist. If the input netlist is in another format that the Netlister 
Launcher recognizes, the Netlister Launcher invokes the 
program necessary to convert the netlist to ED1F or XNF format, 
then invokes the appropriate netlist reader, EDIF2NGD or 
XNF2NGD. 

With the default Netlister Launcher options, NGDBuild recog¬ 
nizes and processes files with the extensions shown in the 
following table. NGDBuild searches the top-level design netlist 
directory for a netlist file with one of these extensions in the order 
shown in this table. For example, NGDBuild searches for an XTF 
file first. If one is not found, it then searches for an XG file and so 
forth. 


Netlist Type 

Recognized Extensions 

XNF 

.xtf, .xg, .xff, .sxnf, .xnf 

ED1F 

.sedif, .edn. .edf, .edit 

PLD 

Pld 
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Note: Remove all out of date netlist files from your directory. Obso¬ 
lete netlist files may cause errors in NGDBuild. 

• UCF file—User Constraints File. This file Ls an ASCII file that you 
create. You can create this file using the Constraints Editor. See 
the Constraints Editor Guide for more information. Tire file 
contains timing and layout constraints that affect how the logical 
design is implemented in the target device. Tire constraints in the 
file are added to the information in the output NGD file. 

By default. NGDBuild reads the constraints in the UCF file auto¬ 
matically if the UCF file has the same base name as the input 
design file and a .ucf extension. You can override the default 
behavior and specify a different constraints file by entering a -uc 
option to the NGDBuild command line. 

• NCF file—Netlist Constraints File. Produced by a CAE vendor 
toolset, this file contains constraints specified within the toolset. 
Tire netlist reader invoked by NGDBuild reads the constraints in 
this file if the NCF file has the same name as the input netlist file. 
It adds the constraints to the intermediate NGO file and the 
output NGD file. 

Note: If the NGO file for a netlist file is up to date, NGDBuild looks 
for an NCF file with the same base name as the netlist in the netlist 
directory and compares the timestamp of the NCF file against that of 
the NC.O file. If the NCF file is newer. XNF2NGD or EDIF2NGD is 
run again. However, if an NCF file existed on a previous run of 
NGDBuild and the NCF file was deleted, NGDBuild does not detect 
that XNF2NGD or EDIF2NGD must be run again. In this case, you 
must use the -nt on option to force a rebuild. 

• NGC file—Binary file containing the implementation of a module 
in the design. If an NGC file exists for a module. NGDBuild reads 
this file directly, without looking for a source ED1F or XNF 
netlist. In HDL design flows, LogiBLOX creates an NGC file to 
define each module. 

• NMC files—Physical Macros. These binary files contain the 
implementation of a physical macro instantiated in the design. 
NGDBuild reads the NMC file to create a beliavioral simulation 
model for the macro. 

• MEM files—LogiBLOX Memory Definition Files. These text files 
define the contents of LogiBLOX memory modules. NGDBuild 
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reads MEM files in design flows where LogiBLOX does not create 
NGC files directly. See the "Module Descriptions" chapter of the 
LogiBLOX Guide for details. 

Unless a full path is provided to NGDBuild, it searches for netlisl. 
NGC, NMC, and MEM files in the following locations. 

• Tire working directory from which NGDBuild was invoked 

• Tire path specified for the top-level design netlist on the 
NGDBuild command line 

• Any path specified with the -sd switch on the NGDBuild 
command line 

Output Files 

Output from NGDBuild consists of the following files. 

• NGD file—Binary file containing a logical description of the 
design in terms of both its original components and hierarchy 
and the NGD primitives to which the design reduces. 

• BLD file—Build report file containing information about the 
NGDBuild run and about the subprocesses run by NGDBuild. 
Subprocesses include ED1F2NGD. XNF2NGD. and programs 
specified in the URF file. The BLD file has the same root name as 
the output NGD file and a .bid extension. The file is written into 
the same directory as the output NGD file. 

Note: If you attach a pull-up or pull-down property on a pad net in 
your UCF file, a comment in the BLD file indicates that NGDBuild 
added a pull-up or pull-down instance to the net. 

Intermediate Files 

NGO files—(Not shown in the "NGDBuild Design Flow" figure) 
Binary files containing a logical description of the design in terms of 
its original components and hierarchy. These files are created when 
NGDBuild reads the input netlist. If these files already exLst, 
NGDBuild reads the existing files. If these files do not exist or are out 
of date. NGDBuild creates them. 
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NGDBuild Options 

Tills section describes NGDBuild command line options. 

-a (Add PADs to Top-Level Port Signals) 

If the top-level input netlisl is in EDIF format, the -a option causes 
NGDBuild to add a PAD symbol to every signal that is connected to a 
port on the root-level cell. This option has no effect on lower-level 
netlists or on a top-level XNF netlist. 

Whether you need to use -a depends on the behavior of your third- 
party EDIF writer. If your EDIF writer treats pads as instances (like 
other library components), you should not use -a. But if your EDIF 
writer treats pads as hierarchical ports, you should use -a to infer 
actual pad symbols. If you do not use -a where necessary, logic may 
be improperly removed during mapping. 

For EDIF files produced by Mentor Graphics and Cadence, the -a 
option is set automatically; you do not have to enter -a explicitly for 
these vendors. 

Note: The NGDBuild -a option corresponds to the EDIF2NC.D-a 
option. If you run ED1F2NGD on the top-level EDIF netlist sepa¬ 
rately, rather than allowing NGDBuild to run EDIF2NGD, you 
should use the two -a options consistently. 

-dd (Destination Directory) 

-dd ngo_direcloiy 

Tire -dd option specifies the directory for intermediate files (design 
NGO files and netlist files), if the -dd option is not specified, files are 
placed in the current directory. 


Deivlopmenl System Reference Guide 


4-7 




Development System Reference Guide 


-f (Execute Commands File) 

-f command file 

The -f option executes the command line arguments in the specified 
command file. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-I (Libraries to Search) 

-1 libname 

The -I option indicates the list of libraries to search when 
determining what library components were used to build the design. 
This option is passed to the appropriate netlist reader. The 
information allows NGDBuild to determine the source of the design's 
components so it can resolve the components to NGD primitives. 

You can specify multiple libraries by entering multiple -1 libname 
entries on the NGDBuild command line. 

Tine allowable entries for libname are the following. 

xilinxun (Xilinx Unified library) 

synopsys 

Note: You do not have to enter xilinxun with a -1 option. Tine Xilinx 
Development System tools automatically access these libraries. In 
cases when* NGDBuild automatically detects Synopsys designs (for 
example, the netlist extension is _sxnf or .sedif), you do not have to 
enter synopsys with a -1 option. 

-nt (Netlist Translation Type) 

-nt Itimestamp I on I off} 

Tine -nt option determines how timestamps are treated by the 
Netlister Launcher when it is invoked by NGDBuild. A timestamp is 
information in a file that indicates the date and time the file was 
created. The timestamp option (which is the default if no -nt option is 
specified) has the Netlister Launcher perform the normal timestamp 
check and update NGO files according to their timestamps. The on 
option translates netlists regardless of timestamps (rebuilding all 
NGO files), and the off option does not rebuild an existing NGO file, 
regardless of its timestamp. 
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-p (Target Architecture) 

-p /wrf 

The -p option specifies the part into which the design is 
implemented .The -p option can specify an architecture only, a 
complete part specification (device, package, and speed), or a partial 
specification (for example, device and package only). 

Tine syntax for the -p option is described in the "Part Numbers in 
Commands" section of the "Introduction" chapter. Examples of part 
entries are XC4000L. XC4003E-PC84. and XC4028EX-HQ240-3. 

When you specify the pari, the NGD file produced by NGDBuild is 
optimized for mapping into that architecture. 

You do not have to specify a -p option if your NGO file already 
contains information about the desired vendor and family (for 
example, if you placed a PART properly in a schematic or a CONFIG 
PART statement in a UCF file). However, you can override the 
information in the NGO file with the -p option when you run 
NGDBuild. 

-r (Ignore LOC Constraints) 

Tlie -r option eliminates all location constraints (LOC=) found in the 
input netlist or UCF file. Use this option when you migrate to a 
different device or architecture, because locations in one architecture 
may not match locations in another. 

Note: If you have run NGDBuild previously on your design and 
NGO files are present, you must use the -nt on option the first time 
you use -r. This forces a rebuild of the NGO files, allowing NGDBuild 
to run ED1F2NGD or XNF2NGD to remove location constraints. 

-sd (Search Specified Directory) 

-ad search /‘ath 

The -sd option adds the specified search path to the list of directories 
to search when resolving file references (that is. files specified in the 
schematic with a FlLE=ft/cHun/c property) and when searching for 
netlist, NGO, NGC. NMC, and MEM files. You do not have to specify 
a search path for the top-level design netlist directory, because it is 
automatically searched by NGDBuild. 
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The search )wtlt must be separated from the -sd by spaces or tabs (lor 
example, -sd designs is correct, -sddesigns is not). 

You can specify multiple -sd options on the command line. Each 
must be preceded with -sd; you cannot combine multiple sotrc/i pith 
specifiers after one -sd. For example, the following syntax is not 
acceptable. 

-sd /horoe/macros/counter /home/designs/pal 2 
Tine following syntax is acceptable. 

-sd /hotae/taacros/counter -sd /hotne/designs/pal 2 

-u (Allow Unexpanded Blocks) 

In the default behavior of NC.DBuild (without -u option), NGDBuild 
generates an error if a block in the design cannot be expanded to 
NGD primitives. If this error occurs, an NGD file is not written. 

If you enter the -u option, NGDBuild generates a warning instead of 
an error if a block cannot be expanded, and writes an NGD file 
containing the unexpanded block. 

You may want to run NGDBuild with the -u option to perform 
pieliminaty mapping, placement and routing, timing analysis, or 
simulation on the design even though the design is not complete. To 
ensure the unexpanded blocks remains in the design when it is 
mapped, run the MAP program with the -u (Do Not Remove Unused 
Logic) option. 

-uc (User Constraints File) 

-uc ucfjile[ . ucf| 

Tire -uc option specifies a UCF (User Constraints File) for the 
Netlister Launcher to read. The UCF file contains timing and layout 
constraints that affect how the logical design is implemented in the 
target device. 

Tine user constraints file must have a .ucf extension. If you specify a 
user constraints file without an extension, NGDBuild appends the 
.ucf extension to the file name. If you specify a file name with an 
extension other than .ucf, you get an error message and NGDBuild 
does not run. 
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If you do not enter a -uc option and a UCF file exists with the same 
base name as the input design file and a .ucf extension. NGDBuild 
automatically reads the constraints in this UCF file. 

The User Constraints File is described in "The User Constraints 
(UCF) File" chapter. 

-ur (Read User Rules File) 

-ur r«/«^/ile[.urf| 

Tine -ur option specifies a user rules file for the Netlister Launcher to 
access. This file deteimines the acceptable netlist input files, the 
netlist readeis that read these files, and the default netlist reader 
options. This file also allows you to specify third party tool 
commands for processing designs. 

Tine user rules file must have a .urf extension. If you specify a user 
rules file with no extension, NGDBuild appends the .urf extension to 
the file name. If you specify a file name with an extension other than 
.urf, you get an error message and NGDBuild does not run. 

Tine user rules file is described in the "User Rules File" section of the 
"ED1F2NGD. XNF2NGD. and NGDBuild" appendix. 

Netlister Launcher 

Tine Netlister Launcher, which is part of NGDBuild. performs any 
netlist translations necessary to execute the NGDBuild command. 
Tine Netlister Launcher is described in detail in the "Netlister 
Launcher" section of the "EDIF2NGD, XNF2NGD, and NGDBuild" 
appendix. 

File Names and Locations 

Following are some notes about file names and notations in 
NGDBuild. 

• An intermediate file has the same root name as the design that 
produced it. An intermediate file is generated when more than 
one netlist reader is needed to translate a netlist to a NGO file. 

• Netlist root file names in the seaich path must be unique. For 
example, if you have the design state.edn, you cannot have 
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another design named state.xnl in any of the directories specified 
in the search path. 

• NGDBuild and the Netlister Launcher support quoted file 
names. Quoted file names may have special characters (for 
example, a space) that are not normally allowed. 

• If the output directory specified in the call to NGDBuild is not 
writable, an error is displayed and NGDBuild fails. 
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The User Constraints (UCF) File 

The UCF file is an ASCII file specifying constraints on the logical design. 
You cicate this file and enter your constraints in the file with a text editor. 

Note: You can also use the Constraints Editoi to create constraints within a 
UCF file. Refer to the Constraints Editor Guide for details. 

These constraints affect how the logical design is implemented in the target 
device. TIk- file can also be used to override constraints specified during 
design entry, earlier in the design flow. 

Theie are several types of logical constraints in the UCF file. 

• Placement 

• Mapping 

• Timing 

• BitGen 

These constraints and the syntax for entering them in the UCF are described 
in the "Attributes. Constraints, and Carry Logic" chapter of the Libraries 
Guide. A more detailed description of timing constraints can be found in the 
"Using Timing Constraints’’ chapter of this manual, the Development System 
Reference Guide. 

The UCF file is an input to NGDBuild <sec the "UCF File Flow” figure). 
The constraints in the UCF file become pan of the information in the NGD 
file produced by NGDBuild. Some of these constraints are used when the 
design is mapped by MAP and some of tl>e constraints arc written into tl«e 
PCF (Physical Constraints File) produced by MAP. The constraints in the 
PCF file aie used by the each of the physical design tools (for example. PAR 
and the timing analysis tools), w hich are run after your design is mapped. 
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Figure 5-1 UCF File Flow 
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Using Timing Constraints 

The liming constraints described in this chapter are compatible with 
the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XLA/XV 

• XC5200 

• Virtex 

• Spartan/XL/2 

For information about using timing constraints with CPLDs, consult 
the CPLD Sch,'malic Design Guide and the CPLD Synthesis Design 
Guide. 

This chapter describes how you specify timing constraints and 
contains the following sections. 

• "Timing Requirements and Xilinx Software" 

• "lOB Register Specification and Reporting" 

• "Entering Timing Specifications" 

• "Specifying Groups" 

• "Defining a Clock Period (PERIOD Constraint)" 

• "OFFSET Timing Specifications" 

• "Ignoring Selected Paths (TIG)" 

• "Basic FROM -TO Syntax" 


Development System Reference Guide—2.li 


6-1 




Development System Reference Guide 


• "Specifying Timing Points" 

• "Using TPTHRU or TPSYNC in a FROM-TO Constraint" 

• "Specifying Time Delay in TS Attributes" 

• "Using the PRIORITY Keyword" 

• "Sample Schematic Using T1MESPEC/TIMEGRP Symbol" 

• "Prorating Constraints" 

• "Additional Timing Constraints" 

• "Constraints Priority" 

• "Syntax Summary" 

Timing Requirements and Xilinx Software 

Xilinx software enables you to specify precise liming requirements 
for your Xilinx FPGA designs. You can specify the timing 
requirements for any nets or paths in your design. One way of 
specifying path requirements is to first identify a set of paths by 
identifying a group of start and end points. The start and end points 
can be flip-flops, I/O pads, latches, or RAMs. You can then control 
the worst-case timing on the set of paths by specifying a single delay 
requirement for all paths in the set. 

Tire primary method of specifying timing requirements is by entering 
them on the schematic. However, you can also specify timing 
requirements in constraints files (UCF and PCF). For detailed 
information about the constraints you can use with your schematic 
entry software, refer to the "Attributes, Constraints, and Carry Logic” 
chapter of the Libraries Guide. 

Once you define liming specifications and then map the design, PAR 
places and routes your design based on these requirements. 

To analyze the results of your timing specifications, use TRACE 
(Timing Report and Circuit Evaluator). Refer to the "TRACE" chapter 
for more information. 
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IOB Register Specification and Reporting 

In the 2.1) release, the Xilinx timing tool analyzes OFFSET and FROM 
TO constraints that include IOB registers. The timing tool reports 
paths that start or end at IOB registers (including paths between 
components). This strategy requires the analysis of paths that 
internally have no length (that is, no components or connections), 
only a setup requirement, for pad-to-setup paths that originate at a 
pad and terminate at the input register within the same IOB. In the 
following example, the pad from the IOB pad to the input register 
IFD is analyzed and reported by the liming tool. 



When these paths are analyzed for either TRACE or PAR. they may 
create timing errors that cannot be corrected because the timing 
requirement is less than the setup time for the I/O register. Under 
these conditions, TRACE always generates a timing error and PAR 
ceases, indicating that the place and route of the design is impossible 
due to existing constraints. 
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Entering Timing Specifications 

Tills section describes the basic methods (or entering timing 
specifications in a schematic or User Constraints File (UCF). 

The following notes apply to Mentor Graphics users. 

• The term attribute in this chapter is equivalent to pmperly as used 
in the Mentor Graphics environment. 

• The Mentor netlist writer (ENWR1TT) converts all property 
names to lowercase letters, and the Xilinx netlist reader 
EDIF2NGD then converts the property names to uppercase 
letters. Because property names are processed in this way, you 
must enter variable text in certain constraints in upper case 
letteis only. This requirement is discussed in the following 
sections. 

• "Entering Timing Specifications in a Schematic" 

• "Creating New Groups from Existing Gioups" 

Entering Timing Specifications in a Schematic 

The TIMESPEC schematic primitive, as illustrated in the "TIMESPEC 
Primitive" figure, serves as a placeholder for timing specifications, 
which are called TS attribute definitions. Every TS attribute must be 
defined in a TIMESPEC primitive, and only TIMESPEC primitives 
can carry TS attribute definitions. Every TS attribute begins with the 
letteis "TS" and ends with a unique identifier that can consist of 
letters, numbers, or the underscore character (_)• 

TS attribute definitions can be any length, but only 30 characters are 
displayed in the TIMESPEC window. Each TIMESPEC primitive can 
hold up to eight TS attributes. If you want to include more than eight 
TS attributes, you can use multiple TIMESPEC primitives in your 
schematic. 
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Figure 6-1 TIMESPEC Primilive 

How you add a TIMESPEC primilive lo your schematic depends on 
your specific schematic-entry software. Refer to the appropriate 
Xilinx Interface Guide for step-by-step instructions. 

A TS attribute defines the allowable delay for paths in your design. 
The basic syntax for a TS attribute is as follows. 

TSidentifiei -FROM souru_group TO dest^group delay 

TSidentifier is a unique name for the TS attribute, source_group and 
desl_group am groups of start points and end points, and delay defines 
the maximum delay for the paths between the start points and end 
points. The delay parameter defines the maximum delay for the 
attribute. Nanoseconds are the default units for specifying delay time 
in TS attributes. You can also specify delay using other units, such as 
picoseconds or megahertz. 

Note: Keywords, such as FROM, TO. and TS appear in the 
documentation in upper case; however, you can enter them in the 
TIMESPEC primitive in either upper or lower case. The character in 
the keywords must be all upper case or all lower case. Examples of 
acceptable keywords am: FROM. TO, from, to. Examples of 
unacceptable keywords are: From, To, fRoM, tO. 

Note: The Mentor netlist writer (ENVV'RITE) converts all property 
names to lower case letters, and the Xilinx netlist reader EDIF2NGD 
then converts the property names to upper case letters. To ensure 
references from one constraint to another are processed correctly, a 
TSidentifier name should contain only upper case letters on a Mentor 
Schematic (TSMA1N, for example, but not TSmain or TSMain). 


Development System Reference Guide 


6-5 












Development System Reference Guide 


Also, if a ISidentifuer name is referenced in a properly value, it must 
be entered in upper case letters. For example, the TS1D1 in the second 
constraint below must be entered in upper case letters to match the 
TSID1 name in the first constraint. 

TSID1 ■ FROM grl TO gc2 50; 

TSMAIN ■ FROM here TO there TSID1 /2; 

Tire basic TS attribute is described in detail in the "Basic FROM -TO 
Syntax” section. More detailed forms of the attribute are also 
described in that section. 

Note: A colon may be used as a separator instead of a space in all 
timing specifications. 

Entering Timing Specifications in a Constraints File 

You can enter timing specifications as constraints in a UCF file. When 
you then run NGDBuild on your design, your timing specifications 
are added to the design database as part of the NGD file. 

To avoid manually entering timing constraints in a UCF file, use the 
Xilinx Constraints Editor, a tool that greatly simplifies constraint 
creation. For a detailed description of how to use the editor, see the 
Constraints Editor Guide. 

The basic syntax for a timing specification entered in a constraints file 
is the TS attribute syntax described in the “Basic FROM -TO Syntax" 
section. 

Although not required, Xilinx recommends that NET and INST 
names be enclosed in double quotes to avoid emirs. Additionally, 
inverted signal names that contain a tilde, for example, -OUTSIG1, 
must always be enclosed in double quotes. Other special characters 
that must be enclosed in quotes are the asterisk (*) and question mark 
<?>• 

You can use the wildcard character (*} to traverse the hierarchy of a 
directory within a UCF or NCF file. Consider the following direcloiy 
hierarchy. 
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With the example hierarchy. the following specifications illustrate the 
scope of the wildcard. 


HIST 

• 

*> 

<everyLhing> 

HIST 

/* 

•> 

<everything> 

HIST 

/*/ 

•> 

<$Al,$Bl,$Cl> 

HIST 

5AI/* 

-> 

<$A21 , $A22, $A3, $A4> 

HIST 

5AI/*/ 

*> 

<$A21,$A22> 

HIST 

5AI/*/* 

-> 

<$A3,$A4> 

HIST 

SA1/*/*/ 

*> 

<$A3> 

HIST 

SA1/*/*/* 

•> 

<$A4 > 

HIST 

5AI/*/*/*/ 

*> 

<$A4> 

HIST 

/*/*22/ 

•> 

<$A22,$B22,$C22> 

INST /*/*22 -> 

<$A22,SA3,SA4, $B22, 

. $B3,$C22, $C3> 

HIST 

/•/•22/> 

•> 

<5A3, 5A.1,5B3. SC22.SC3 


Specifying Groups 

In a TS attribute, you specify the set of paths to be analvztxi by 
grouping start and end points in one of the following ways. 

• Refer to a predefined group by specifying one of the 
corresponding keywords — FF5, PADS. LATCHES, or RAMS. 

• Cieate your own groups within a predefined gnmp by lagging 
symbols with TNN1 (pronounced tee-name) attributes. 

• Cieate groups that are combinations of existing groups using 
TIMEGRP symbols. 

• Cieate groups by pattern matching on net names. 

The following sections discuss each method in detail. 
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Using Predefined Groups 


You can refer to a group of flip-flops, inpul latches, pads, or RAMs by 
using the corresponding keywords. 


Keyword 

Description 

FFS 

CLB or lOB flip-flops only; not flip-flops built from 
function generators (Shift Register LUTs are included 
in Virtex and Spartan2 also) 

LATCHES 

CLB or IOB latches only; not latches built from 
function generators 

PADS 

Input/Output pads 

RAMS 

For architectures with RAMS (LUT RAMS and Block 
RAMS are included for Virtex and Spartan2 but Shift 
Register LUTs are not included in RAMS) 


From-To statements enable you to define timing specifications for 
paths between predefined groups. The following examples are TS 
attributes that reside in the T1MESPEC primitive or are entered in the 
UCF. This method enables you to easily define default timing 
specifications for the design, as illustrated by the following examples. 

Schematic syntax in TIMESPEC primitive 

TS01-FRCM FFS TO FFS 3D 
TS02-FRCM LATCHES TO LATCHES 25 
TS03-FRCM PADS TO PAMS 70 
TS04-FRCM FFS TO PADS 55 

UCF syntax 

TIMESPEC TSOI-FROM FFS TO FFS 30; 

TIMESPEC TS02-FROM LATCHES TO LATCHES 25; 
TIMESPEC TS03-FRCM PADS TO RAMS 70; 

TIMESPEC TS04-FROM FFS TO PADS 55; 

A predefined group can also carry a name qualifier: the qualifier can 
appear any place where the predefined group is used. This name 
qualifier restricts the number of elements being referred to. Tire 
syntax used is as follows. 

predefined group (name qualifier | name qualifier |) 
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mtmejiiialifier is the full hierarchical name of the net that is sourced by 
the primitive being identified. 

Tlie name qualifier can include wildcard characters (*) to indicate any 
number of characters (or ? to indicate a single character) which allows 
the specification of more than one net or allows you to shorten the 
full hierarchical name to something that is easier to type. 

As an example, specifying the group FFS(MACR0 A/Q?) selects 
only the flip-flops driving the QO. Ql, Q2 and Q3 nets in the 
following macro. 


MACRO A 



*7411 


Figure 6-2 Using Qualifiers with Predefined Groups 

To create rnorc specific groups see the following section. 
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Creating User-Defined Groups Using TNMs 

A TNM (liming name) is an allribule lhal can be used lo identify the 
elements lhal make up a group which can then be used in a liming 
specification. A TNM is a properly lhal you place directly on your 
schematic lo lag a specific net, element pin, primitive or macro. 

All symbols lagged with I he TNM identifier are considered a group. 
Place TNM attributes directly on your schematic or in a UCF file 
using the following syntax. Special rules apply when using TNM 
with the PERIOD constraint for Virtex CLKDLLs. Refer to the 
"PERIOD Specifications on CLKDLLs" section. 

Schematic syntax 

TNM=iilcntifier 

UCF syntax 

|NET I INST I PINI object name THMmidentifier; 

identifier is a value that consists of any combination of letters, 
numbers, or underscores. Keep the TNM short for convenience and 
clarity. 

Do not use the reserved woids FFS, LATCHES, PADS, RAMS, 
RISING, FALLING, TRANSHI. TRANSLO, or EXCEPT, as identifiers. 
Tire constraints in the table below are also reserved words and 
should not be used as identifiers. 


Reserved Words (Constraints) 

ADD 

FAST 

NODELAY 

ALU 

FBK1NV 

OPT 

ASSIGN 

FILE 

OSC 

BEL 

F SET 

RES 

BLKNM 

HBLKNM 

RLOC 

CAP 

HU SET 

RLOC ORIGIN 

CLKDV DIVIDE 

H SET 

RLOC RANGE 

CLBNM 

1N1T 

SCHNM 

CMOS 

1N1T OX 

SLOW 

CYMODE 

INTERNAL 

STARTUP WAIT 

DECODE 

lOB 

SYSTEM 
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Reserved Words (Constraints) 

DF.F 

IOSTANDARD 

TNM 

DIVIDE 1 BY 

L1BVER 

TRIM 

D1VIDE2 BY 

LOC 

TS 

DOUBLE 

LOWPWR 

TTL 

DRIVE 

MAP 

TYPE 

DUTY CYCLE 
CORRECTION 

MEDFAST 

USE RLOC 

EQN 

MEDSLOVV 

U SET 

FAST 

MINIM 



Note: It you want to use a keyword as an identifier, you can enclose 
the keyword in quotation marks. In the TNM statement TNM-RAMS 
-CMOS', CMOS is treated as an identifier instead of a keyword. 


You can specify as many groups of end points as an? necessary to 
describe the performance requirements of your design. However, to 
simplify the specification process and reduce the place and route 
time, use as few groups as possible. 

A predefined group can be used in a TNM specification, using the 
following syntax on a schematic or UCF file. 

Schematic syntax 

TXH-predefinedgroup identifier 

UCF syntax 

I NET I INST I PIN) object name THH-predefined.group identifier; 

The object jiame is the net, pin, or instance name. 

The predefined group is one of the groups (for example, FFS or RAMS) 
defined in the "Using Predefined Groups" section and identifier is a 
value that consists of any combination of letters, numbers, or 
underscores. Paths defined by the TNM are traced forward if placed 
on a net or pin, through any number of gates or buffeis, until they 
reach a member of the predefined group. That element is added to the 
specified TNM group. TNM does not trace through the element to the 
next element; forward tracing stops at the element. 
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Tills mechanism is called forward tracing. If TNM is placed on an 
instance, paths am traced "downward" through a hierarchy instead 
of forward along a net. 

Note: If a TNM is placed on an input pad net, the constraint only 
applies to the input pad. In that case, refer to the "Creating User- 
Defined Groups Using TNM NET" section. 

The specification shown below, when attached to a net. would create 
a group called FIFO CORE consisting of all of the RAM primitives 
traced forward on the net. The specification shows the schematic and 
UCF syntax. 

Schematic syntax 

TNM-RAMS FIFO CORE 

UCF syntax 

NET net. name TNM-RAMS FIFO CORE; 

The following figure illustrates the preceding TNM identifier. The 
two RAMs traced forward from the net are included in the group. 
The flip flop is not. 
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TNM? RAMS'.FIFO CORE 


0 ? 



O 

AO 


A! 


A2 


A3 


A4 




XBS26 


Figure 6-3 TNM Placed on a Net 

A defined nel In a TNM statement can have a name qualifier (for 
example, TNM=FFS (FRED*) GRP A), as described in Ihe “Creating 
Groups by Pattern Matching’’ section. 

You can use several methods for tagging groups of end points 
placing identifiers on nets, macro or primitive pins, primitives, or 
macro symbols. Which method you choose depends on hoiv the path 
end points are related in your design. For each of these elements, you 
can use Ihe predefined group syntax described earlier in this section. 

The following subsections discuss the different methods of placing 
TNMs in your design. The same TNM attribute can be used as many 
ways and as many times as necessary to get the TNM applied to all of 
the elements in the desired group. 

You can place TNM attributes in either of two places: in the schematic 
as discussed in this section or in a constraints file (UCF or NCF). 
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The syntax for specifying TNMs in a UCF or NCF constraints file is 
described in the "Attributes, Constraints, and Carry Logic" chapter of 
the Libraries Guide. 

Placing TNMs on Nets 

Tine TNM attribute can be placed on any net in the design. The 
attribute indicates that the TNM value should be attached to all valid 
elements fed by all paths that fan forward from the tagged net. 
Forward tracing stops at any flip-flop, latch, RAM or pad. See the 
"TNM Placed on a Net” figure. TNMs do not propagate across IBUFs 
if they are attached to the input pad net. Also refer to the "Creating 
User-Defined Groups Using TNM NET" section. 

Placing TNMs on Macro or Primitive Pins 

Tine TNM attribute can be placed on any macro or component pin in 
the design if the design entry package allows placement of attributes 
on macro or primitive pins. The attribute indicates that the TNM 
value should be attached to all valid elements fed by all paths that fan 
forward from the tagged pin. Forward tracing slops at any flip-flop, 
latch. RAM or pad. The following illustration shows the valid 
elements for a TNM attached to the schematic a macro pin. 
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Figure 6-4 TNM Placed on a Macro Pin 

The syntax lor the UCF file would be 
PIN pin mine TWM-FFS FLOPS; 

Placing TNMs on Primitive Symbols 

You can group individual logic primitives explicitly by flagging each 
symbol, as illustrated by the following figure. 
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Figure 6-5 TNM on Primitive Symbols 

In the figure, the flip-flops tagged with the TNM form a group called 
"‘FLOPS.” The untagged flip-flop on the right side of the drawing is 
not part of the group. 

Place only one TNM on each symbol, driver pin. or macro driver pin. 
Schematic syntax 
TNM-FLOPS 
UCF syntax 

INST synbol.name TNM-FLOPS; 

Placing TNMs on Macro Symbols 

A macro Ls an element that performs some general purpose higher 
level function. It typically has a lower level design that consists of 
primitives, other macros, or both, connected together to implement 
the higher level function. An example of a macro function is a lo-bit 
counter. 
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A TNM attribute attached to a macro indicates that all elements 
inside the macro (at all levels of hierarchy below the tagged macro) 
are part of the named group. 

When a macro contains more than one symbol type and you want to 
group only a single type, use the TNM identifier in conjunction with 
one of the predefined groups: FFS. RAMS, PADS, or LATCHES as 
indicated by the following syntax examples. 

Schematic syntax 

TNM-FFS identifier 
TNM"RAMS identifier 
TNM-LATCHES identifier 
THM-PADS identifier 

UCF syntax 

INST «acro_name TNM-FFS identifier; 

INST nacro_name TNM-PAMS identifier; 

INST tnacro_name TNM-LATCHES identifier; 

INST macro_name TNM-PADS identifier; 

If multiple symbols of the same type are contained in the same 
hierarchical block, you can simply flag that hierarchical symbol, as 
illustrated by the following figure. In the figure, all flip-flops 
included in the macro are tagged with the TNM "FLOPS". By tagging 
the macro symbol, you do not have to tag each underlying symbol 
individually. 
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Figure 6-6 TNM on Macro Symbol 

Placing TNMs on Nets or Pins to Group Flip-Flops 
and Latches 

You can easily group flip-flops, latches, or both by flagging a 
common input net, typically either a clock net or an enable net. If you 
attach a TNM to a net or driver pin, that TNM applies to all flip-flops 
and input latches that are reached through the net or pin. That is, that 
path is traced forward, through any number of gates or buffers, until 
it reaches a flip-flop or input latch. That element is added to the 
specified TNM group. 

The following figure illustrates the use of a TNM on a net that traces 
forward to create a group of flip-flops. 
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In the figure, the attribute TNM=FLOPS traces forward to the first 
two flip-flops, which form a group called FLOPS. The bottom flip- 
flop is not part of the group FLOPS. 



Figure 6-7 TNM on Net Used to Group Flip-Flops 

Tlie following figure illustrates placing a TNM on a clock net. which 
traces forward to all three flip-flops and forms the group Q FLOPS. 


Deivlopmenl System Reference Guide 


6-19 




Development System Reference Guide 



«&531 


Figure 6-8 TNM on Clock Pin Used lo Group Flip-Flops 

The TNM parameter on nets or pins is allowed to have a qualifier. 
For example, on schematics 

TNM=FFS data 
TNM*RAMS fifo 
TNM=IATCHES capture 

In UCF files 

|NET I PIN} net _or jiinjtanu TNM=FFS data; 

|NET I PIN) net orjfin name TNM-RAMS fifo; 

INET I PIN! net or pin name TNM=LATCHES capture; 

A qualified TNM is traced forward until it reaches the first storage 
element (flip-flop, latch, or RAM). If that type of storage element 
matches the qualifier, the storage element is given that TNM value. 
Whether or not there is a match, the TNM is not traced through that 
storage element. 
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TNM parameters on nets or pins are never traced through a storage 
element (flip-flop, latch or RAM). 

Creating User-Defined Groups Using TNM NET 

A TNM NET (timing name for nets) is an attribute that can be used 
to identify the elements that make up a group which can then be used 
in a timing specification. Essentially TNM NET is equivalent to TNM 
on a net except for pad nets. Special rules apply when using 
TNM NET with the PERIOD constraint for Virlex CLKDLLs. Refer to 
the "PERIOD Specifications on CLKDLLs" section. 

A TNM NET is a property that you normally use in conjunction with 
an HDL design to tag a specific net. All nets tagged with the 
TNM NET identifier am considered a group. The UCF syntax is as 
follows. 

NET net, name TNM HET=identifier; 

identifier is a value that consists of any combination of letters, 
numbers, or underscores. Keep the TNM NET short for convenience 
and clarity. The basic syntax rules for TNM NET and TNM are 
identical. Refer to the "Creating User-Defined Groups Using TNMs" 
section for details. 

The TNM NET attribute can be used to define certain types of nets 
that cannot be adequately described by the TNM constraint. This 
attribute is specifically targeted for use in HDL designs. 

For example, consider the following design. 


FFA 



Development System Reference Guide 


6-21 




Development System Reference Guide 


In the preceding design, a TNM associated with the PAD symbol 
only includes the PAD symbol as a member in a timing analysis 
group. For example, the following UCF file entry creates a time group 
that includes the IPAD symbol only. 

NET PADCLK TNM=PADS<») PADGRP; (UCF file example) 

However, using TNM to define a time group for the net PADCLK 
creates an empty time group. 

NET PADCLK TNM=FFS (*) FFGRP; (UCF file example) 

All properties that apply to a pad are transferred from the net to the 
PAD symbol. Since the TNM is transferred from the net to the PAD 
symbol, the qualifier, ~FFSf*)'' does not match the PAD symbol. 

To overcome this obstacle for schematic designs using TNM, you can 
create a time group for the 1NTCLK net. 

NET INTCLK TNM=FFS (*) FFGRP; (UCF file example) 

However, for HDL designs, the only meaningful net names are the 
ones connected directly to pads. Then, use TNM NET to create the 
FFGRP time group. 

NET PADCLK TNM NET=FFS {*) FFGRP; (UCF file example) 

NGDBuild does not transfer a TNM NET attribute from a net to a 
PAD as it does with TNM. 

TNM NET can be used in NCF or UCF files as a property attached to 
an object in an input netlist (ED1F or XNF). TNM NET is not 
supported in PCF files. 

TNM NET can only be used with nets. If TNM NET is used with any 
other object such as a pin or symbol, a warning is generated and the 
TNM NET definition is ignored. 

Creating New Groups from Existing Groups 

In addition to naming g to ups using the TNM identifier, you can also 
define groups in terms of other groups. You can create a group that is 
a combination of existing groups by defining a TIMEC.RP attribute as 
follows. 

Schematic syntax in TIMEGRP primitive 
neivgroupaexisting_grpl existing _grp2 | existing grpi .. .| 
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UCF syntax 

TIMEGRP nemgn>upmexisting_grpl existing j$r/>2 [ existing_grp3.. .|; 

neivgroup is a newly created group that consists of existing groups 
created via TNMs, predefined groups, or other TIMEGRP attributes. 

Tine Mentor netlist writer (ENWRITE™) converts all property names 
to lower case letters, and the Xilinx netlist reader ED1F2NGD then 
converts the property names to uppercase letters. To ensure 
references from one constraint to another are processed correctly, 

• Group names should contain only upper case letters on a Mentor 
Schematic (MY FLOPS, for example, but not my flops or 

My flops). 

• If a group name appears in a property value, it must also be 
expressed in upper case letteis. For example, the GROUP3 in the 
first constraint below must be entered in upper case letters to 
match the GROUP3 in the second constraint. 

Schematic syntax in TIMEGRP primitive 

GROUP1 * gr2 GROUP3 
GROUP3 = FFS except grp5 

UCF syntax 

TIMEGRP GROUP1 = gr2 GROUP3; 

TIMEGRP GROUP3 = FFS except grp5; 

TIMEGRP attributes reside in tire TIMEGRP primitive, as illustrated 
in the figure below. Once you create a TIMEGRP attribute definition 
within a TIMEGRP primitive, you can use it in the TIMESPEC 
primitive. Each TIMEGRP primitive can hold up to eight group 
definitions. Since your design might include more than eight 
TIMEGRP attributes, you can use multiple TIMEGRP primitives. 
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X4330 

Figure 6-9 TIMEGRP Primitive 

You can place TIMEGRP attributes in either of two places: in the 
TIMEGRP primitive on the schematic as discussed in this section or 
in a constraints file (UCF or NCF). The syntax for specifying 
TIMEGRPs in a UCF or NCF constraints file is described in the 
"Attributes, Constraints, and Carry Logic” chapter of the Libraries 
Guide. 

You can use TIMEGRP attributes to create groups using the following 
methods. 

• Combining multiple groups into one 

• Creating groups by exclusion 

• Defining flip-flop subgroups by clock sense 

Tire following subsections discuss each method in detail. 

Combining Multiple Groups into One 

You can define a group by combining other groups. The following 
syntax example illustrates the simple combining of two groups. 

Schematic syntax in TIMEGRP primitive 

big group=small group medium group 

UCF syntax 

TIMEGRP big group=small group medium group; 
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In this syntax example, small group and medium group are existing 
groups defined using a TNM or TIMEGRP attribute. Within the 
TIMEGRP primitive, TIMEGRP attributes can be listed in any order; 
that is, you can create a TIMEGRP attribute that references another 
TIMEGRP attribute that appears after the initial definition. 

Note: A circular definition, as shown below, causes an error when 
you run your design through NGDBuild. 

Schematic syntax in TIMEGRP primitive 

nony_ffs-ffsi ffs 2 
££si-mnny_f£s f£s3 

UCF syntax 

TIMEGRP »any_ffs-ffsl ffs2; 

TIMEGRP ££sl-many_ffs ££s3; 

Creating Groups by Exclusion 

You can define a group that includes all elements of one group except 
the elements that belong to another group, as illustrated by the 
following syntax examples. 

Schematic syntax in TIMEGRP primitive 

grouplmgroup2 EXCEPT group3 

UCF syntax 

TIMEGRP groupl *group2 EXCEPT group.!; 

• groupl represents the group being defined. It contains all of the 
elements in group! except those that are also in group3. 

• group2 and group3 can be a valid TNM, predefined group, or 
TIMEGRP attribute. 

As illustrated by the following example, you can specify multiple 
groups to include or exclude when creating the new group. 

Schematic syntax in TIMEGRP primitive 

groupl *group2 group3 EXCEPT groupl groups 

UCF syntax 

TIMEGRP groupl mgroup2 group3 EXCEPT group! greupS; 
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The example defines a groupl Ihal includes the members of group2 
and groups, except for those members that are part of gmup4 or 
groups. All of the groups before the keyword EXCEPT are included, 
and all of the groups after the keyword are excluded. 

Certain reserved words cannot be used as group names. These 
reserved words are described in the "Creating User-Defined Groups 
Using TNMs" section. 

Defining Flip-Flop Subgroups by Clock Sense 

You can create subgroups using the keywords RISING and FALLING 
to group flip-flops triggered by rising and falling edges. 

Schematic syntax in TIMEGRP primitive 

groupl-RISING ffs 
group2-RISING ffs_group 
group3-FALLING ffs 
groups-FALLING ffs_group 

UCF syntax 

TIMEGRP groupl-RISING ffs; 

TIMEGRP group2-RISING ffs_group; 

TIMEGRP group3-FALLING ffs; 

TIMEGRP group4-FALLING ffS_group; 

group1 to group4 are new groups being defined. The^jfnnp must be 
a group that includes only flip-flops. 

Note: Keywords, such as EXCEPT, RISING, and FALLING, appear in 
the documentation in upper case, however, you can enter them in the 
TIMEGRP primitive in either lower or upper case. You cannot enter 
them in a combination of lower and upper case. 

Tile following example defines a group of flip-flops that switch on 
the falling edge of the clock. 

Schematic syntax in TIMEGRP primitive 

falling_ffs-FALLING ffs 

UCF syntax 

TIMEGRP falling_ffs-FALLING ffs; 
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Defining Latch Subgroups by Gate Sense 

Croups of lype LATCHES (no mailer how Ihese groups are defined) 
can be easily separated inlo transparent High and transparent low 
subgroups. The TRANSHI and TRANSLO keywords are provided 
for this purpose, and are used in T1MEGRP statements like the 
RISING and FALLING keywords for flip-flop groups. For example 

Schematic syntax in T1MEGRP primitive 

lo*group-TRAflSLC latchgroup 
highgroup-TRANSHI latchgroup 

UCF syntax 

TIMEGRP lo*group-TRANSLO latchgroup; 

TIMEGRP highgroup-TRANSHI latchgroup; 

Creating Groups by Pattern Matching 

When creating groups, you can use wildcard characters to define 
groups of symbols whose associated net names match a specific 
pattern. 

How to Use Wildcards to Specify Net Names 

The wildcaid characters, * and ?. enable you to select a group of 
symbols whose output net names match a specific string or pattern. 
Tlie asterisk (') represents any string of zero or more characters. The 
question mark (?) indicates a single character. 

For example, DATA' indicates any net name that begins with 
' DATA," such as DATA. DATA 1, D ATA22, DATABASE, and so on. 
Tine string NUMBER? specifies any net names that begin with 
"NUMBER" and end with one single character, for example. 
NUMBER1, NUMBERS but not NUMBER or NUMBER12. 

You can also specify more than one wildcard character. For example. 
'AT? specifies any net names that begin with any series of characters 
followed by "AT" and end with any one character such as BAT1, 
CAT2. and THAT5. If you specify 'AT??, you would match BATll, 
CAT26. and THAT50. 
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Pattern Matching Syntax 

Tine syntax lor creating a group using pattern matching is shown 
below. 

Schematic syntax in T1MEGRP primitive 
group^p redefined group {patient) 

UCF syntax 

TIMEGRP group=predefined. group (ju/lcrii) ; 

predefined ^grotty can only be one of the following predefined groups— 
FFS. LATCHES. PADS, or RAMS. The pattern is any string of 
characters used in conjunction with one or mom wildcard characters. 

Note: When specifying a net name, you must use its full hierarchical 
path name so PAR can find the net in the flattened design. 

For flip-flops, input latches, and RAMs. specify the output net name. 
For pads, specify the external net name. 

Tine following example illustrates creating a group that includes the 
flip-flops that source nets whose names begin with SI 13/FRED. 

Schematic syntax in TIMEGRP primitive 

gioupi-ffs($113/FRED*) 

UCF syntax 

TIMEGRP gioupl-f f3 t$113/FRED*); 

Tine following example illustrates a group that excludes certain flip- 
flops whose output net names match the specified pattern. 

Schematic syntax in TIMEGRP primitive 

this_group-£fs EXCEPT ffsta*) 

UCF syntax 

TIMEGRP this_group-ffs EXCEPT ffsta*); 

In this example, this group includes all flip-flops except those 
whose output net names begin with the letter "a." 

Tine following defines a group named "some latches". 

Schematic syntax in TIMEGRP primitive 

soM_latches-latches (5113/xyz*) 
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UCF syntax 

TIMEGRP aome_latche8-latchea($113/xyz*); 

Tlie group some latches contains all Input latches whose output 
net names start with "S113/xy2." 

Additional Pattern Matching Details 

In addition to using pattern matching when you create timing 
groups, you can specify a predefined group qualified by a pattern 
any place you specify a predefined group. The syntax below illus¬ 
trates how pattern matching can be used within a timing specifica¬ 
tion. 

Schematic syntax in TIMESPEC primitive 

TSid.vftf/n'=FROM predefined group (pattern) TO 
/>redefined. group 
(pattern) delay 

UCF syntax 

TIMESPEC TSidentifier =FROM predefined ^group (pattern) TO 
predefined group (pattern) delay; 

Instead of specifying just one pattern, you can also specify a list of 
patterns separated by a colon (:) as illustrated below. 

Schematic syntax in TIMEGRP primitive 

satr*_ffs-f fs (a* :b?:c*d) 

UCF syntax 

TIMEGRP some_ff»-ffa(a*:b?:c*d); 

The group some t fa contains flip-flops whose output net names 
adhere to one of the following rules. 

• Start with the letter "a" 

• Contain two characters, the first character is "b" 

• Start with "c" and end with "A" 


Development System Reference Guide 


6-29 




Development System Reference Guide 


Defining a Clock Period (PERIOD Constraint) 

A dock period specification checks timing clocked by the net fall 
pa tits that terminate at a register clocked by the specified net). 

The period specification is attached to the clock net. The definition of 
a clock period is unlike a FROM-TO style specification because the 
timing analysis tooLs automatically lake into account any inversions 
of the clock net at register clock pias. 

A PERIOD constraint on the dock net in the following figure would 
generate a check for delays on all paths that terminate at a pin that 
has a setup or hold timing constraint relative to the dock net. This 
could include the data paths D1 loCLBl.D, CLB1.Q to CLB2.D, as 
well as the path EN to CLB2.EC (if the enable were synchronous with 
respect to the dock). 



law 


Figure 6-10 Paths lor PERIOD Constraint 

In 2.1 i, the timing tool no longer checks pad-to-register paths relative 
to setup requirements. For example in the preceding figure, the path 
from D1 to Pin D of CLB1 is no longer included in the PERIOD 
constraint. 

Simple Method 

A simple method of defining a clock period is to attach the fcillotving 
attribute directly to a net in the path that drives the register clock 
pins. 
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Schematic syntax 

PERIOD »period | HIGH I LOW} [high, orjowjime] 

UCF syntax 

|period JlemJ period * period ! high I low } 
[Itigh_orJou.’Jinie\ ; 

period item is one of the following, 

• NET " neijtame" 

• T1MEGRP " groupjume" 

• ALLCLOCKNETS (PCF only) 

period is the required clock period. The default units are nanoseconds, 
but the timing number can be followed by ps, ns, us, or ms. Units 
may be entered with or without a leading space, and an? case- 
insensitive. The HIGH LOW keyword indicates whether the first pulse 
in the period is high or low, and the optional high or tow lime is the 
duty cycle of the first pulse. If an actual time is specified, it must be 
less than the period. If no high or low time is specified the default 
duty cycle is 50%. The default units for high or lowjime is ns, but the 
number can be followed by % or by ps, ns, us or ms if you want to 
specify an actual time measurement. 

Tine PERIOD constraint is forward traced in exactly the same way a 
TNM would be and attaches itself to all of the flip-flops that the 
forward tracing reaches. If a more complex form of tracing behavior 
is required (for example, where gated clocks are used in the design), 
you must place the PERIOD on a particular net or use the preferred 
method described next. 

Preferred Method 

Tine preferred method for defining a clock period allows more 
complex derivative relationships to be defined as well as a simple 
clock period. The following attribute is attached to a TIMESPEC 
symbol in conjunction with a TNM attribute attached to the relevant 
clock net. 

Schematic syntax in a T1MSPEC symbol 

TSiiffrth/iff-PERIOD TNM . reference period (HIGH LOW| 
[high_orJowJime\ 
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UCF syntax 

TIMESPEC TSidentifier*PERIOD TNM reference period (HIGH I 
LOW' [high or low time]; 

identifier is a reference identifier that lias a unique name. 

TNM reference is the identifier name that is attached to a clock net (or 
a net in the clock path) using a TNM attribute. 

• NET " netjuime" 

• T1MEGRP "group _name~ 

• ALLCLOCKNETS 

The variable name period is the tequiied clock period. The default 
units for period are nanoseconds, but the number can be followed by 
ps. ns, us, or ms. Units may be entered with or without a leading 
space, and are case-insensitive. The HIGH I LOW keyword indicates 
whether the first pulse in the period is high or low, and the optional 
or /ore time is the polarity of the first pulse. If an actual time is 
specified, it must be less than the period. If no high or low time is 
specified the default duty cycle is 50%. The default units for 
high or low time is ns, but the number can be followed by % or by ps, 
ns, us, or ms if you want to specify an actual time measurement. 

Example 

Clock net sys_clk has the attribute inr-.-r.aster _clk attached to it 
and the following attribute is attached to a TIMESPEC primitive. 

Schematic syntax in a TIMESPEC symbol 

TS master=PERIOO master elk 50 HIGH 30 

UCF syntax 

TIMESPEC TS master=PERIOD master elk 50 HIGH 30; 

Tills period constraint applies to the net master elk. and defines a 
clock period of 50 nanoseconds, with an initial 30 nanosecond high 
time- 
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Specifying Derived Clocks 

Tlie preferred method of defining a clock period uses an identifier, 
allowing another clock period specification to reference it. To define 
the relationship in the case of a derived clock, use the following 
syntax. 

Schematic syntax in a T1MSPEC symbol 

TSiifi’/rff/irr=PERIOD TNM. reference another PERIOD identifier 
|(/l*|»Miwl¥r] IIHIGHILOW! high or Jow time] 

UCF syntax 

TIMESPEC TSulentifier-PERIOD TNM reference 

another .PERIOD .identifier 

]]/\ •\nurnber] (IHIGH I LOW! high _orJowJirne]; 

• identifier is a reference identifier that lias a unique name. 

• TNM reference is the identifier name that is attached to a clock net 
or a net in the clock path using a TNM attribute. 

• another PERIOD identifier is the name of the identifier used on 
another period specification. 

• number is a floating point number. 

• The HIGH I LOW keyword indicates whether the first pulse in the 
period is high or low, and the optional high_orJou<Jime is the 
polarity of the first pulse. If an actual time is specified it must be 
less than the period. If no high or low time is specified, the 
default duty cycle is 50%. The default units for high or low lime 
is ns, but the number can be followed by % or by ps, ns, us, or ms 
if you want to specify an actual time measurement. 

Example 

A clock net has the attribute tnm=s!ave_dk attached to it and the 
following attribute is attached to a TIMESPEC primitive. 

Schematic syntax in a TIMESPEC symbol 

ta_alavel-PERIOD alave_clk TS_maater *4 
UCF syntax 

TIMESPEC ta_alavel“PERIOD alave_clk TS_maater 
*4; 
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PERIOD Specifications on CLKDLLs 

A TNM or TNM NET group on a net is usually traced forward to tag 
all of the flip-flops, latches, and RAMs driven by that net. However, if 
the group traces into the clock input pin of a Virtex or Spartan2 
CLKDLL or CLKDLLHF symbol, it is not simply traced through the 
CLKDLL outputs. 

When a TNM or TNM NET group is traced into the CLKIN pin of a 
Virtex CLKDLL component, NGDBuild examines the TNM group to 
ensure that it meets all the following conditions. 

• Used in only one PERIOD specification 

• Not used in a FROM-TO or OFFSET specification 

• Not referenced in any user group definition 

Note: If a group Ls traced into the CLKDLL but is not used in exactly 
one PERIOD specification, NGDBuild issues an error. To tag the 
elements driven by the CLKDLL, place TNM or TNM NET groups 
directly on the CLKDLL output nets. 

If the TNM or TNM NET group meets these conditions, NGDBuild 
copies the PERIOD specification to each CLKDLL output net and 
adjusts it as shown in the following table. 
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Output Pin 

Adjustments 

CLKO 

CLK90 

CLK180 

CLK270 

If the DUTY CYCLE CORRECTION=TRUE property is found, the duty 
cycle is adjusted to 50%/50%. 

If DUTY CYCLE _CORRECTION=FALSE is found, the duty cycle is 
unchanged from the original PERIOD specification. 

If the DUTY CYCLE CORRECTION property is not found, the default 
value of TRUE Ls assumed. 

CLK2X 

If originally expressed as FREQUENCY, the FREQUENCY value is 
doubled. 

If originally expressed as PERIOD, the PERIOD value is divided in half. 

The duty cycle Ls adjusted to 50%/50%. 

CLKDV 

If originally expressed as FREQUENCY, the FREQUENCY value is 
divided by the value in the CLKDV DIVIDE property. 

If originally expressed as PERIOD, the PERIOD value is multiplied by 
the value in the CLKDV DIVIDE property. 

If the CLKDV. DIVIDE value is not found, the default value of 2.0 is 
used. 

The duty cycle Ls adjusted to 50%. 


In addition to creating new PERIOD specifications at the CLKDLL 
outputs. NC.DBuild also creates new TNM or TNM NET groups to 
use in those specifications. The new groups are traced forward from 
the CLKDLL output net to tag all flip-flops. latches, and RAMs 
controlled by that clock signal. 

Each new TNM or TNM NET group created by NC.DBuild is named 
the same as the corresponding CLKDLL output net.The TSidentifier 
for the new PERIOD specification uses the TS prefix followed by the 
net name. These new groups and specifications are shown in timing 
analysis reports. 

Tine following figure indicates how new groups are created at the 
outputs of the DLL for a TNM NET group specification at the 
CLKDLL inputs. 
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The sample PERIOD specification for the figure is as follows: 

TIMESPEC TS01=PERIOD CLK1 10 HIGH 3ns 


I MU HtliCLK HCT 


CL£m 


CLKM 


CLKDIL 


TMU HfcT 


cuuju 


TMII htlzm 


"^TSWiltfiOO * HKJH Sna 


LOCKfcO 


Figure 6-11 TNM_NET Generation 

Note: The new TNM or TNM NET groups and PERIOD 
specifications are not visible in the Constraints Editor, because they 
are created from the user-applied specification each time NGDBuild 
is run. 

OFFSET Timing Specifications 

Offsets are used to define the liming relationship between an external 
clock and its associated data-in or data-out pin. Using this option 
allows you to do the following. 

• Calculate whether a setup lime is being violated at a llip-fiop 
whose data and dock inputs are derived from external nets. 

• Specify the delay of an external output net derived from the Q 
output of an internal flip-flop being docked from an external 
device pin. 

Following are some of the advantages of using the OFFSET 
constraint. 

• Includes the clock path delay for each indiv idual synchronous 
elements 

• Subtracts the clock path delay from the data path delay for inputs 
and adds the dock path delay to tire data path delay for outputs 

• Includes paths for all synchronous element types (FFS, RAMS, 
and LATCHES) 
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• Utilizes a global syntax that allows all inputs or outputs to be 
constrained by a clock 

• Allows specifying IO constraints either directly as the setup and 
clock-to-out required by a device (IN BEFORE and OUT AFTER) 
or indirectly as the time used by the path external to the device 
(IN AFTER and OUT BEFORE) 

Tile re are basically three types of offset specifications. 

• Global 

• Net-specific 

• Group 

Since the global and group OFFSET constraints are not associated 
with a single data net or component, these two types can also be 
entered on a TIMESPEC symbol in the design netlist with Ts id. 

Schematic syntax in a TIMESPEC symbol 

TSiif=|TlMEGRP name] offset = | in I out! offset time limits! 
(BEFORE I AFTER! dkjuuue |TIMEGRP group name] 

UCF syntax 

|TIMEGRP name] OFFSET « (IN OUT| offset time [i/mtsl 
(BEFORE I AFTER! elkjmme (TIMEGRP group name]; 

Note: In the UCF file, you cannot specify the TS id format. 

See the next section and the "Group OFFSET” section for syntax 
details. As with the PERIOD and MAXDELAY timing specifications, 
if the same TS id is defined in the design netlist (or NCF) and the UCF 
file, the UCF file takes precedence. 

The following subsections describe the use of each type of OFFSET in 
PCF and UCF files and explain the scope of each specification. 

Global OFFSET 

Release 2. li supports the use of the global OFFSET constraint. Release 
2.1i also supports the use of time groups within global OFFSET 
constraints. On a schematic, enter the global OFFSET in the 
TIMESPEC symbol. 

UCF syntax 
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OFFSET = (INI OUT] offset Jime [units] (BEFORE IAFTER} 
elk nil me (TIMEGRP group jtame\; 

PCF syntax 

OFFSET = |IN I OUT] offset Jiiue\unils\ 'BEFORE 1 AFTER! COMP 
clkjobjiame (TIMEGRP group, namej ; 

offset Jime is the external offset and units is an optional field that 
indicates the units for the offset time. The default units am 
nanoseconds, but the timing number can be followed by ps, ns, us, 
ms, GHz, MHz, or KHz to show the intended units. 

Tine UCF syntax variable clkjtome is the fully hierarchical net name of 
the clock net between its pad and its input buffer. 

Tine elk Job mime is the block name of tine clock IOB. 

Tine optional TIMEGRP groiip_iunne defines a group of registers that 
will be analyzed. By default, all registers clocked by elk name will be 
analyzed. 

IN I OUT specifies that the offset is computed with respect to an input 
IOB or an output IOB. For a bidirectional IOB. the IN I OUT syntax 
lets you specify the flow of data (input or output) on the IOB. 

BEFORE I AFTER indicates whether data is to arrive (input) or leave 
(output) the device before or after the clock input. 

All inputs/outputs are offset relative to elk name or iob name. For 
example. OFFSET IN 20 ns BEFORE clkl dictates that all inputs 
will have data present at the pad at least 20 ns before the triggering 
edge of elk 1 arrives at the pad. 
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Net-Specific OFFSET Constraints 

The OFFSET constraint can also be used to specify a constraint for a 
specific data net in a UCF file or schematic or a specific input or 
output component in a PCF file. 

Schematic syntax when attached to a net 

OFFSET = (IN I OUT | offset Jime [l/»ll'/sl 'BEFORE I AFTER I 
elk name (TIMEGRP group_name] 

UCF syntax 

NET name OFFSET = |INlOUT| offset lime [units] 

I BEFORE I AFTER! elkjtame (TIMEGRP group name]; 

PCF syntax 

COMP "idtjtame" OFFSET = | IN I OUT) offset Jime limits) 

I BEFORE I AFTER' COMP “elkjob name" (TIMEGRP 
"group, name ']; 

Tine PCF file uses blocks (comps) instead of nets. 

II COMP "iob name" is omitted in the PCF or NET "name" is omitted 
in the UCF, the specification is assumed to be global. 

offset Jime is the external offset. 

unite is an optional field that indicates the units for offset time. Tine 
default units are in nanoseconds, but the timing number can be 
followed by ps, ns, us, GHz, MHz, or KHz to indicate the intended 
units. 

elk iobjiame Ls the block name of the clock IOB. 

It is possible for one offset constraint to generate multiple data and 
clock pa tins (for example, when both data and clock inputs have more 
than a single sequential element in common). 

Examples 

Tine offset constraint examples in this section apply to the following 
figures. 
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FPGA Boundary 



Figure 6-12 OFFSET Example Schematic 
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Figure 6-13 OFFSET IN Timing Diagram 


'OUT BEFORE 


O OUT 


CLK SYS 



Figure 6-14 OFFSET OUT Timing Diagram 
Example 1— OFFSET IN BEFORE 

OFFSET IN BEFORE defines the available time for data to propagate 
from the pad and setup at the synchronous element (COMP). The 
time can be thought of as the time differential of data arriving at the 
edge of the device before the next dock edge arrives at the device. See 
the “OFFSET Example Schema tic v figure and the "OFFSET IN Timing 
Diagram" figure. The equation that defines this relationship is as 
follows. 
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t data + T su * t c:lk £ t in_before 

For example, if T|^ BEFORE ei | u - , l s 20 ns, the following syntax applies. 
Schematic syntax attached to DATA IN 

OFFSET=IN 20.0 BEFORE CLK SYS 

UCF syntax 

NET DATA IN OFFSET=IN 20.0 BEFORE CLK SYS; 

PCF syntax 

COMP DATA IN OFFSET=IN 20.0 ns BEFORE COMP 
CLK SYS; 

Tills constraint indicates that the data will be present on the 
DATA IN pad at least 20 ns before the triggering edge of the clock 
net arrives at the clock pad. 

To ensure that the timing requirements are met, the timing analysis 
software verifies that the maximum delay along the path DATAIN to 
COMP (minus the 20.0 ns offset) would be less than or equal to the 
minimum delay along the reference path CLOCK to COMP. 

Example 2 — OFFSET IN AFTER 

Tills constraint describes the time used by the data external to the 
FPGA. OFFSET subtracts this time from the PERIOD declared for the 
chick to determine the available time for the data to propagate from 
the pad and setup at the synchronous element. The time can be 
thought of as the differential of data arriving at the edge of the device 
after the current clock edge arrives at the edge of the device. See the 
'OFFSET Example Schematic" figure and the "OFFSET OUT Timing 
Diagram" figure. The equation that defines this relationship is as 
follows. 

t data + Tsu * t c:lk —Tp - t in_after 
Tp is the clock period. 

For example, if T| N ^FIER equals 30 ns. the following syntax applies. 
Schematic syntax attached to DATA IN 

OFFSET=IN 30.0 AFTER CLK SYS; 
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UCF syntax 

NET DATA IN OFFSET=IN 30.0 AFTER CLK SYS; 

FCF syntax 

COMP DATA IN OFFSET=IN 30.0 ns AFTER CCMP 
CLK SYS; 

Tills constraint indicates that the data will arrive at the pad of the 
device (COMP) no more than 30 ns after the triggering edge of the 
clock arrives at the clock pad. The path DATA IN to COMP would 
contain the setup time for the COMP data input relative to the 
CLK.SYS input. 

Verification is almost identical to Example 1, except that the offset 
margin (30.0 ns) is added to the data path delay. This is caused by the 
data arriving after the reference input. The liming analysis software 
verifies that the data can be clocked in prior to the next triggering 
edge of the clock. 

A PERIOD or FREQUENCY is required only for offset OUT 
constraints with the BEFORE keyword or offset IN with the AFTER 
keyword. 

Example 3 — OFFSET OUT AFTER 

This constraint defines the time available for the data to propagate 
from the synchronous element to the pad. This lime can also be 
considered as the differential of data leaving the edge of the device 
after the current clock edge arrives at the edge of the device. See the 
'OFFSET Example Schematic" figure and the "OFFSET OUT Timing 
Diagram” figure. 

The equation that defines this relationship is as follows. 
t q + t co + t cik ^- t out_after 

For example, if Tq|j T a pier equals 35 ns, the folkiwing syntax 
applies. 

Schematic syntax attached to Q OUT 

OFFSET^OUT 35.0 AFTER CLK SYS 

UCF syntax 

NET Q OUT OFFSET=OUT 35.0 AFTER CLOCK; 
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FCF syntax 

COMP Q OUT OFFSET=OUT 35.0 ns AFTER COMP 
CLK SYS; 

Tills constraint calls for the data to leave the FPGA 35 ns after the 
present clock input arrives at the clock pad. The path COMP to 
Q OUT would include the CLOCK-to-Q delay (component delay). 

Verification involves ensuring that the maximum delay along the 
reference path (CLK SYS to COMP) and the maximum delay along 
the data path (CO.YIP to Q OUT| does not exceed the specified offset. 

Example 4 — OFFSET OUT BEFORE 

Tills constraint defines the time used by the data external to the 
FPGA. OFFSET subtracts this time from the clock PERIOD to 
determine the available time for the data to propagate from the 
synchronous element to the pad. The time can also be considered as 
the differential of data leaving the edge of the device before the next 
ckxk edge arrives at the edge of the device See the "OFFSET Example 
Schematic" figure and the "OFFSET OUT Timing Diagram" figure. 
The equation that defines this relationship is as follows. 

Tq + T co + T clk <_Tp - T OLrr BEFORE 

For example, if T^yj BEFORE ^cjuals 15 ns. the following syntax 
applies. 

Schematic syntax attached to Q OUT 

OFFSET^OUT 15.0 BEFORE CLK SYS 

UCF syntax 

NET Q OUT OFFSET=OUT 15.0 BEFORE CLK SYS; 

PCF syntax 

COMP Q OUT OFFSET=OUT 15.0 ns BEFORE COMP 
CLK SYS; 

This constraint states that the data clocked to Q OUT must leave the 
FPGA 15 ns before the next triggering edge of the clock arrives at the 
ckxk pad. The path COMP to Q OUT includes the CLK SYS-to-Q 
delay (component delay). The data clocked to Q OUT will leave the 
FPGA 15.0 ns before the next clock input. 
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Verification involves ensuring that the maximum delay along the 
reference path (CLK SYS to COMP) and the maximum delay along 
the data path (COMP to Q OUT} do not exceed the clock period 
minus the specified offset. 

As in Example 2. a PERIOD or FREQUENCY constraint is required 
only for offset OUT constraints with the BEFORE keyword or offset IN 
with the AFTER keyword. 

Specific OFFSET Constraints with Timegroups 

A clock register time group allows you to define a specific set of 
registers to which an OFFSET constraint applies based on a clock 
edge. Consider the following example. 



X54!H1 


Figure 6-15 Using Timegroups with Registers 

You can define time groups for the registers A, B and C. even though 
these registers have the same data and clock source. The syntax is as 
follows. 

Schematic syntax in TIMEGRP primitive 

AB=RISING FFS 
C ^FALLING FFS; 

UCF /PCF syntax 

TIMEGRP AB=RISING FFS; 

TIMEGRP C ^FALLING FFS; 
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Schematic syntax attached to DATA 

OFFSET=IN 10 BEFORE CLOCK TIMEGRP AS 
OFFSET=IN 20 BEFORE CLOCK TIMEGRP C 

UCF syntax 

NET DATA OFFSET=IN 10 BEFORE CLOCK TIMEGRP AB; 
NET DATA OFFSET=IN 20 BEFORE CLOCK TIMEGRP C; 

PCF syntax 

COMP DATA OFFSET=IN 10 BEFORE COMP CLOCK TIMEGRP 
AB; 

CCMP DATA OFFSET=IN 20 BEFORE COMP CLOCK TIMEGRP 

C; 

Even though the registers A. D and C have a common data and clock 
source, timing analysis applies two different offsets < 10 ns and 20 ns). 
Registers A and D belong to the offset with 10 ns and Register C 
belongs to the offset with 20 ns. 

However, you must use some caution when using timegroups with 
registers. Consider the following diagram. 



XB459 

Figure 6-16 Problematic Timegroup Definition 


Dnvlopmenl System Reference Guide 


6-45 

























Development System Reference Guide 


Tills circuit is identical to the "Using Timegroups with Registers" 
figure except that an inverter has been inserted in the path to Register 
B. In this instance, even though this register is a member of the time 
group whose offset triggers on the rising edge, the addition of the 
inverter classifies register B as triggering on the falling edge like 
Register C. 

Normally, the tools will move an inverter to the register, in which 
case, B would be a part of the timegroup "Falling". However if the 
clock is gated with logic that inverts, then the inverter will not 
become part of the register. In that case, one way to solve this 
problem is to create a timegroup with an exception for Register B. See 
the "Creating Croups by Exclusion" section for details. 

Group OFFSET 

You can also define OFFSET constraints within the TiMESPEC 
primitive with a leading T1MEGRP reference. 

Schematic syntax in TIMESPEC primitive 

TSiifi’/tfi/iVr=TIMEGRP name OFFSET^ |IN OUT! offset time 
limits] IBEFORE AFTER] clk_name (TIMEGRP group name | 

The UCF and PCF syntax do not require the TSidenlifier. 

UCF syntax 

ITIMEGRP name] OFFSET^ |IH OUT) offsetJinte[units] 
Ibefore I after! dk^imme |timegrp group name]; 

PCF syntax 

ITIMEGRP name] OFFSET^ |IN OUT' offset Jinte |iim'fs] 
IBEFORE I AFTER! COMP elk job name |TIMEGRP group name]; 

The timing group specified at the beginning has a different purpose 
than the timegroup specified at the end. The first time group is a list 
of data pads that the OFFSET applies to, while the last time group 
(register time group) is a list of synchronous elements that specifies 
which register elements clocked by elk name or elk Job name should 
be analyzed. 

Note: If the first group has FFs or the second group has PADS. 
NGDBuild generates an error. 

offset Jime is the external offset. 
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units is an optional field that indicates the units for offset time. The 
default units are in nanoseconds, but the timing number can be 
followed by ps, ns, us, GHz, MHz, or KHz to indicate the intended 
units. 

elk Jobjumie is the block name of the clock IOB. 

Ignoring Selected Paths (TIG) 

In a design, some paths do not require timing analysis. These are 
paths that exist in the design, but are never used during time-critical 
operations. If you indicate a timing requirement on these paths, more 
important paths might be slower, which can result in failure to meet 
the timing requirements. 

The value of TIG may be any of the following. 

• Empty (global TIG that blocks all paths) 

• A single TSid to block 

• A comma separated list of TSids to block, for example 

NET SlI567/$Sig 5TIG=TS fast, TS even faster; 

To indicate that all timing specifications through a net, primitive pin 
or macro pin are to be ignored, attach the following attribute to the 
desired element. 

Schematic syntax 

TIG 

UCF syntax 

|NET I PIN I INSTANCE] Ilrft/ICTIG; 

If this attribute is attached to a net, primitive pin, or macro pin, all 
paths that fan forward from the point of application of the attribute 
are treated as if they don't exist for the purposes of timing analysis 
during implementation. In the following figure, NET C is ignored. 
However, note that the lower path of NET B that runs through the 
two OR gates would not be ignored. 
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Figure 6-17 TIG Example 

The following attribute would be attached to a net to inform the 
timing analysis tools that it should ignore paths through the net for 
specification TS43: 

Schematic syntax 

TIG « TS43 

UCF syntax 

NET net, name TIG * TS43; 

You cannot perform path analysis in the presence of combinatorial 
loops. Therefore, the timing tools ignore certain connections to break 
combinatorial loops. You can use the TIG constraint to direct the 
timing tools to ignore specified nets or load pins, consequently 
controlling how loops are broken. 

Basic FROM -TO Syntax 

Within tiie TIMESPEC primitive, you use the following syntax to 
specify timing requirements between specific end points. 

TS ideatifie /=FROM source group TO dtst m gnup delay 

TSii/t7?f(/jtv=FROM saurce\gtoup delay 

TSidentifiermTO dest,group delay 
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Unspecified FROM or TO. as in Ihe second and third syntax 
statements, implies all points. 

Tine From-To statements are TS attributes that reside in the 
T1MESPEC primitive. The parameters Mime_group and dat^roup must 
be one of the following. 

• Predefined groups 

• Previously created TNM identifiers 

• Croups defined in TI.MEGRP symbols 

• TPSYNC groups 

Predefined groups consist of FFS. LATCHES. RAMS, or PADS and 
are discussed in the "Using Predefined Croups" section. TNMs are 
introduced in the "Creating User-Defined Croups Using TNMs" 
section. TIMECRP symbols are introduced in the "Creating New 
Croups from Existing Croups" section. 

Note: Keywords, such as FROM. TO. and TS appear in the 
documentation in upper case; however, you can enter them in the 
T1MESPEC primitive in either upper or lowercase. You cannot enter 
them in a combination of lower and upper case. 

Tine delay parameter defines the maximum delay for the attribute. 
Nanoseconds are the default units for specifying delay time in TS 
attributes. You can also specify delay using other units, such as 
picoseconds or megahertz. 

Refer to the "Specifying Time Delay in TS Attributes" section later in 
this chapter for more information on time delay. The delay can be a 
function of another TIMESPEC (TS01*2). 

Tine following examples illustrate the use of From-To TS attributes. 

Schematic syntax in TIMESPEC primitive 

TS01-FRCM FFS TO FFS 3D 
TS_OTHER-FRCM PADS TO FFS 25 
TS_THIS-FRCM FFS TO RAMS 35 
TS_THAT-FRCM PADS TO LATCHES 35 

UCF syntax 

TIMESPEC TSOl-FROM FFS TO FFS 30; 

TIMESPEC TS_OTHER-FROM PADS TO FFS 25; 
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TIMESPEC 7SJTHIS-FRCM FFS TO RAMS 35; 

TIMESPEC TS — THAT-FROM PADS TO LATCHES 35; 

You can place TS attributes containing From-To statements in either 
of two places: in the TIMESPEC primitive on the schematic as 
discussed in this chapter or in a constraints (UCF) file. 

Specifying Timing Points 

There are situations where a particular point or set of points in your 
design needs to be flagged for reference in subsequent timing 
specifications. Timing points are used for these specifications. 

There are two types of timing points. 

• A TPSYNC timing point is used to allow a point to be used as the 
start or the end of timing path, even though the point may not 
apply to a flip-flop, latch. RAM or I/O pad. 

• A TPTHRU timing point identifies an intermediate point on a 
path. 

Tire following sections describe how these timing points are 
specified. 

Using TPSYNC to Define Synchronous Points 

There are cases where the timing of a design must be defined from or 
to a point in the design that is not a flip-flop, latch, RAM or I/O pad. 
For example, you might want to specify a point at the output of a 
latch defined using a function generator instead of a latch symbol. 
Tire TPSYNC timing point identifies one or a group of these points. 

A TPSYNC attribute has the following syntax. 

Schematic syntax 

TPSYNC ■ identifier 

UCF syntax 

|NET I PIN I INST] TPSYNC= identifier; 
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identifier is a name that is used in timing specifications in the same 
way that groups an? used. The same identifier can be used on several 
points which are then treated as a group from the point of view of 
timing analysis. The identifier must be different from any identifier 
used for a TNM attribute. 

The way a TPSYNC timing point is used depends on the object to 
which it is attached. 

• Attached to a net. TPSYNC identifies the source of the net as a 
potential source or destination for liming specifications. 



X8524 


• Attached to an output macro pin, TPSYNC identifies all of the 
sources inside the macro Ilial drive the pin to which the attribute 
is attached as potential sources or destinations for timing 
specifications. In the following diagram. POINTY applies to the 
inverter. 


Developntenl System Reference Guide 


6-51 















DfvdopmiU System Reference Guide 



X4MI 


Figure 6-18 TPSYNCs Attached to Macro Pins 

If the macro pin is an input pin (that is, there are no sources for 
the pin in the macro), then all of the load pins in the macro are 
flagged as synchronous points. In the preceding figure POINTX 
applies to the input AND gale. 

• Attached to a primitive pin. TPSYNC flags the primitive's pin as 
a potential source or destination for timing specifications; 
TPSYNC applies to the pin it is attached to. 

• Attached to a primitive symbol, TPSYNC identifies the output(s) 
of that element as a potential source or destination for liming 
specifications. See the following figure. 


TPSYNC=POINTX 
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The use of a TPSYNC liming point to define a synchronous point in a 
design implies that the flagged point cannot be merged into a 
function generator. For example, consider the following diagram. 


Function Function 

Generator Generator 






TPSYNC-FOO 



X8758 


In this example, because of the TPSYNC definition, the two gates 
cannot be merged into a single function generator. 

Using TPTHRU to Define Through Points 

The TPTHRU attribute defines an intermediate point in a path. A 
point or group defined with TPTHRU attributes is used in detailed 
timing specifications. 

A TPTHRU attribute has the following syntax. 

TPTHRU = identifier 

identifier is a name that is used in timing specifications in the same 
way that groups are used. The same identifier can be used on several 
points which are then treated as a group from the point of view of 
timing analysis. 

The identifier must be different from any identifier used for a TNM 
attribute or TPSYNC. 

Timing specifications using TPTHRU groups are described in the 
"Specifying Time Delay in TS Attributes" section. 


Deielopmenl System Reference Guide 


6-53 










Development System Reference Guide 


Using TPTHRU or TPSYNC in a FROM-TO 
Constraint 

U is sometimes convenient to deline intermediate points on a path to 
which a specification applies. This defines the maximum allowable 
delay and lias the following syntax. 

Schematic syntax in TIMESPEC primitive 

TSident ifie /=F ROM source group THRU Ihrujmnt |THRU 
thru_point\ TO dest_group allowable_delay [miffs] 

T Side lit if it ’'=F ROM SOUrce_group THRU llwujtoint [THRU 
linn point] allowobtejlelay limits] 

T S hit’ll I ifie >=T H RU thru^point [THRU Ihiu point] TO dest group 
allowable delay [miffs] 

UCF syntax 

TIMESPEC TS idealifit’ r«FROM source .group THRU tliru_poinl 
[THRU ffim_/*>iiif] TO dest group allowablejteiay [miffs|; 

TIMESPEC TSidenff/iir^FROM SOUrce_group THRU thru joint 
[THRU thru />oiiit] allowable delay [miffs]; 

TIMESPEC TSfden/ffier-THRU thrujtoinl [THRU thru fieiiil] 
alloii'tible.detay [miffs] ; 

Unspecified FROM or TO. as in the second and third syntax state¬ 
ments, implies all points. 

• identifier is an ASCII string made up of the characters A..Z, a..z, 
0..9, underbar (_), and forward slash (/). 

• source_group and dest group are user-defined, predefined groups 
or TPSYNCs. 

• thru .point is an intermediate point used to qualify the path, 
defined using a TPTHRU attribute. 

• allowable delay is the timing requirement. 

• miffs is an optional field to indicate the units for the allowable 
delay. Default units are nanoseconds, but the timing number can 
be followed by ps, ns, us, ms, GHz, MHz. or KHz to indicate the 
intended units. 
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The example shows how to use the TPTHRU attribute with the 
THRU attribute on a schematic. The UCF syntax is as follows. 

INST FLOPA TNM-A; 

INST FLOPB TNM=B; 

NET MYNET TPTHRU-ABC 

TIMESPEC TSp*thl=FROM A THRU ABC TO B 30; 

The following schematic shows the placement of the TPTHRU 
attribute and the resultant path that is defined. 



Figure 6-19 TPTHRU Example 

Specifying Time Delay in TS Attributes 

Nanoseconds are the default units for specifying delay times in TS 
attributes. However, after specifying the maximum delay or 
minimum frequency numerically, you can enter the unit of measure 
by specifying the following. 

• PS for picoseconds, NS for nanoseconds, US for microseconds, or 
MS for milliseconds 

• MHZ for megahertz. KHZ for kilohertz, or GHz for gigahertz 
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As an alternate way of specifying time delay, you can specify one 
time delay in terms of another. Instead of specifying a time or 
frequency in a TS attribute definition, you can specify a multiple or 
division of another TS attribute. This is useful in a system where all 
clocks are derived from a master clock; in this situation, changing the 
timing specification for the master clock changes the specification for 
all clocks in the system. 

Use the syntax below to specify a TS attribute delay in terms of 
another. 

Schematic syntax attached to TIMESPEC primitive 

TSidentifier=s;tecification reference TS <if tribute) |* I /)number] 

UCF syntax 

TIMESPEC TSidentifiermspecificntion reference TS attribute) |* I / 
(number); 

number can be either a whole number or a decimal. The specification 
can be any From-To statement as illustrated by the following 
examples. 

FRCM PADS TO PADS 
FROM groupl TO group2 
FROM tnm_identifier TO FFS 
FROM LATCHES TO groupl 

Use """ to represent multiplication and “to represent division. The 
specification type of the reference TS attribute does not need to be the 
same as the TS attribute being defined; however, it must not be 
specified in terms of TIG. 

Examples 

Examples of specifying a TS attribute in terms of another are as 
follows. In these cases, assume that the reference attributes were 
specified as delays (not frequencies). 

In the example below, the paths between flip-flops and pads are 
placed and routed so that their delay is at most 10 times the delay 
specified in the T505 attribute. 

Schematic syntax in TIMESPEC primitive 

TS08-FRCM FFS TO PADS TSDS'lD 
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UCF syntax 

TIMESPEC TSOB-FRCM FFS TO PADS TS0B*10; 

In the example below, the paths between input and output pads are 
placed and routed so that their delay is at most one-eighth the delay 
specified in the T507 attribute. 

Schematic syntax in TIMESPEC primitive 

TS1-FRCW PADS TO PADS TS07/8 
UCF syntax 

TIMESPEC TSI-FROM PADS TO PADS TS07/8; 

Note: When a reference attribute is specified as a frequency, a 
multiple represents a faster specification; a division represents a 
slower specification. 

You can also specify a TS attribute in terms of a TS attribute that is 
already a specification of another. The following example provides 
an illustration. 

Schematic syntax in TIMESPEC primitive 

TS09-FRCM FFS TO FFS BO 
TS10-FRCM FFS TO PADS TS09*2 
TS1I-FRCM PADS TO PADS TS10M 

UCF syntax 

TIMESPEC TS09-FRCM FFS TO FFS BO; 

TIMESPEC TSIO-FROM FFS TO PADS TS09*2; 

TIMESPEC TS11-FROM PADS TO PADS TS10M; 
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Using the PRIORITY Keyword 

There may be situations where there is a conflict between two 
TIMESPECs that cover the same path. In these cases you can define 
the priority of a T1MESPEC using the following syntax. 

normal fimespec synlav PRIORI TV integer 

normalJitnespec syntax is a legal TIMESPEC and integer represents 
the priority (the smaller the number, the higher the priority). The 
number can be positive, negative, or zero, and the value only lias 
meaning when compared with other PRIORITY values. 

Note: The PRIORITY keyword cannot be used with the MAXDELAY, 
or MAXSKEW constraint. 

Sample Schematic Using TIMESPEC/TIMEGRP 
Symbol 

TNM identifiers define symbols or groups of symbols that are used in 
timing specifications. They can also define other groups. The 
following figure shows an example of a TNM attribute attached to an 
individual symbol. In this cireuit. the flip-flop D FF has the attribute 
TNM=D_FF attached to it. 
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Figure 6-20 Example of Using TNMs and TIMEGRPs in a 
Schematic 

Tine TIMEGRP symbol contains an attribute that defines a group of 
flip-flops called Q FFS, which includes all flip-flops in the schematic 
except the one labeled D FF. You can then use the group Q FFS to 
create timing specifications in the TiMESPEC primitive. The flip-flop 
D FF has its clock enable driven at 1 /2 of the clock frequency, 
therefore, its flip-flop to pad and pad to flip-flop timing specifications 
are longer than the flip-flop to pad specifications in the Q FFS group. 
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Prorating Constraints 

Tine prorating constraints. VOLTAGE and TEMPERATURE, provide 
a method for determining timing delay characteristics based on 
known environmental parameters. On a schematic, you can enter 
these constraints in any empty space. For Release 2.1i these two 
constraints are supported for XC4000XL/XLA. New speed file 
releases for existing architectures will support these two constraints. 

Note: Prorating is not intended for military and industrial ranges. It 
is applicable only within the commercial ranges. 

VOLTAGE Constraint 

Tills constraint allows the specification of the operating voltage. This 
provides a means of prorating delay characteristics based on the 
specified voltage. 

Note: Each architecture has its own specific range of supported 
voltages. If the entered voltage does not fall within the supported 
range, the constraint is ignored and an architecture-specific default 
value is used instead. The UCF syntax is as follows. 

VOLTAGE* nr/wc (units 1 

value is an integer or real number specifying the voltage and units is 
an optional parameter specifying the unit of measure. V specifies 
volts, the default voltage unit. 

TEMPERATURE Constraint 

Tills constraint allows the specification of the operating temperature 
which provides a means of prorating device delay characteristics 
based on the specified junction temperature. Prorating is a linear 
scaling operation on existing speed file delays and is applied globally 
to all delays. 

Note: Each architecture has its own specific range of valid operating 
temperatures. If the entered temperature does not fall within the 
supported range, the constraint is ignored and an architecture- 
specific default value is used instead. The UCF syntax is as follows. 

TEMPEPATURE=:vr/llC[C IF I K, 


6-60 


Xiliux Development System 




Using Timing Constraints 


value is an integer or a leal number specifying the temperature. C. K. 
and F are the temperature units: F is degrees Fahrenheit. K is degrees 
Kelvin, and C is degrees Celsius, the default. 

Additional Timing Constraints 

There are additional properties and constraints you can specify for 
the timing analysis tools. They are the following. 

• Net skew control (MAXSKEVV) 

• Net delay control 

• Path tracing control 

• The DROP SPEC constraint 

Controlling Net Skew (MAXSKEW) 

Skew is the difference between the minimum and maximum of the 
maximum load delays on a net. You can control the maximum 
allowable skew on a net by attaching the MAXSKEW attribute 
directly to the net. Syntax is as follows. 

skew item MAXSKEW «?//ini'i7Wc .skew [mi//s|; 

allowuble _skew is the timing requirement. 

The default units for allowable jkew are nanoseconds, but the timing 
number can be followed by ps, ns, us, ms, GHz, MHz, or KHz to 
indicate the intended units. 

skewjtem is one of the following. 

• NET "netjumie" 

• T1MEGRP “group name' 1 (PCF only) 

• ALLCLOCKNETS (PCF only) 

Note: T1MEGRP and ALLCLOCKNET5 are supported in PCF files 

only. 

It is important to understand exactly what MAXSKEW defines. 
Consider the following example. 
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Figure 6-21 MAXSKEW 

In the preceding diagram, for t a (l,2). 1 ns is the minimum delay and 2 
ns is the maximum delay for the Register A dock. For f b (2,4) # 2 ns is 
the minimum delay and *1 ns is the maximum delay for the Register B 
clock. MAXSKEW defines the maximum of t b minus the maximum of 
t^. that is. *1-2=2. Since the data delay Ls greater than MAXSKEW <DD 
is 23 while MAXSKEW is 2). no race condition occurs. However. 
MAXSKEW does not account for the circumstance when? one of the 
rcgislers Ls operating at minimum delay (for example. 1^=1) while a 
second register is operating at maximum delay (for example, l b =4). 
Under (hose conditions, the skew is 3 ns (t b - l a = 3). Since the data 
delay (DD = 2.5) Ls less than the skew, a race condition exists. 

Controlling Net Delay (MAXDELAY) 

You can control the maximum allowable delay on a net by attaching 
the MAXDELAY attribute directly to the net. The UCF syntax is as 
follows. 

net net name maxdelay *palh .value ! priority integer] ; 

TSidentifiei =maxdelay= fxi/Jt path .value \ priority integer ]; 

/uf/j MAXDELAY=|VJ/fi_ru/iic ! priority integer] ; 

net delay jlem MAXDELAY=dt7<jy./j>t;c * units [PRIORITY 
J/rfryWl; 

path is one of the following, 

• PATH "pathjmtie" 

• ALLPATHS 

• FROM group „ item THRU group_itemI.~ group it com 
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• FROM groupJt/in THRU group item I... group iteinn TO 
group Jteni 

• THRU group Jteml... groupJtetitn TO groupJtem 
path value is one of Ihe following, 

• delay_lime lunitsl 

units defaults to nanoseconds, but the delay time number can be 
followed by ps, ns, us, or ms (picoseconds, nanoseconds, 
microseconds, or milliseconds) to specify the units 

• frequency units 

units can be specified as GHz, MHz, or KHz (gigahertz, mega¬ 
hertz, or kilohertz) 

• TSidentifier [|/ I *| real_number] 
net delay .item is one of the following, 

• NET "netjuvne" 

• T1MEGRP "group j\ante~ 

• ALLCLOCKNETS 

Controlling Path Tracing 

Path tracing controls allows you to enable or disable specific paths 
within device components (for example, CLBs and lOBs) for liming 
analysis. These constraints can only be entered in a PCFftle; they cannot 
be applied during design entry or in a UCF or NCF file. 

This constraint can be applied at a global or group scope. The path 
tracing syntax is as follows. 

|TIMEGRP predefined group\ 1 ENABLE I DISABLE} ■ symbol; 

symbol is a component delay symbol, and predefined _group (which is 
optional) represents the name of a previously-defined time group. If 
there is no T1MEGRP predefined _group qualifier, the path tracing 
control applies to all logic celLs in the design. 

The symbol, which is case-insensitive, can be either of the following. 

• A standard component delay symbol name (for example, 
teg sr qortbuf i o, as described in the following table). 
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There is a one-to-many correspondence between these symbol 
names and data book symbol names, and the data book symbols 
to which each standard block delay signal applies varies from 
one device family to another. 

• A component delay specified in the Xilinx Programmable Logic 
Data Book (for example, T (10 (entered as T1LO) or T CCK (entered 
as TCCK)). 


Tire following table describes the standard block delay symbols. 

Table 6-1 Standard Block Delay Symbols for Path Tracing 


Symbol 

Path Type 

Default 

reg,sr_q 

Set/Reset to output propagation 
delay 

Disabled 

reg_sr_clk 

Set/Reset to clock setup and hold 
checks 

Disabled 

lat_d_q 

Data to output transparent latch 
delay 

Disabled 

ram_d_o 

RAM data to output propagation 
delay 

Disabled 

tamwe_o 

RAM write enable to output propa¬ 
gation delay 

Enabled 

tbuf .1.0 

TBUF tristate to output propagation 
delay 

Enabled 

tbuf .i_o 

TBUF input to output propagation 
delay 

Enabled 

io pad i 

IO pad to input propagation delay 

Enabled 

io_t pad 

IO tristate to pad propagation delay 

Enabled 

io_o_i 

IO output to input propagation 
delay. Disabled for Instated IOBs. 

Enabled 

io_o. pad 

IO output to pad propagation delay 

Enabled 


Tire IOB configuration for Virtex and Spartan2 is somewhat different 
than the IOB configuration for other architectures. See the following 
figure. 
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Figure 6-22 Simplified IOB Configurations and io_t_pad 

For the Virtex and Spartan2 IOBs, there is no default path. If a latch is 
used (latch mode) r then io t pad controls the D to Q path through the 
latch. By default D to Q is enabled which is different than other 
internal latches. The clock to Q of the latch is not disabled by 
io_t. pad. 

If a register is used instead of a latch, the clock to Q of the register is 
not disabled by io t pad. 

Path Tracing Examples 

The FCF file constraint below prevents timing analysis on any path 
that includes the I to O delay on a TBUF component. The constraint 
applies to all TBUF components in the design. 

DISABLE - •Lbur_l_o"; 

The PCF file constraint below disables the I to O delay on the TBUF 
components in the gn>up mygroup, if applicable. 

7IMEGRP *mygroup" DISABLE - "tbuf_i_o"; 
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Tine PCF file constrain! below disables line T| ( „ databook component 
delay in the group mygroup, il applicable. 

TIMEGRP ’mygroup" DISABLE - "TILC"; 

Tine delay symbol names in the Xilinx Programmable Logic Do to Book 
do not always agree with the delay names reported in TRACE (the 
Xilinx timing analyzer). To ensure your path tracing constraints are 
processed correctly and to allow your constraints to be portable from 
one device to another, use the delay names reported by TRACE 
instead of the databook names. 

You can control path tracing for a single instance by creating a group 
containing only the instance, then specifying this group in a path 
tracing constraint. 

The DROP_SPEC Constraint 

A constraint specified in a UCF constraints file takes precedence over 
one with the same name in the input design. This allows you to 
redefine or modify constraints without having to edit the input 
design. The DROP SPEC constraint allows you to specify that a 
timing constraint defined in the input design should be dropped 
from the analysis. The UCF syntax is as follows. 

TS identifier * DROP SPEC 

identifier is the identifier name used with another timing specification. 
Tills constraint can be used when new specifications defined in a 
constraints file do not directly override all specifications defined in 
the input design, and some of these input design specifications need 
to be dropped. 

While this timing command is not expected to be used much in an 
input netlist (or NCF file), it is not illegal. If defined in an input 
design this attribute must be attached to a T1MESPEC primitive. 
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Constraints Priority 

In so mo cases, two liming specifications cover the same path. For 
cases where Ihe livo timing specifications on the path are mutually 
exclusive, the following constraint rules apply. 

• Priority depends on the file in which the constraint appears. A 
constraint in a file accessed later in the design flow replaces a 
constraint in a file accessed earlier in the design flow. Priority is 
as follows (first listed is the highest priority, last listed is the 
lowest). 

• Constraints in a Physical Constraints File (PCF) 

• Constraints in a User Constraints File (UCF) 

• Constraints in a Netlist Constraints File (NCF) 

• Attributes in a schematic 

• If two timing specifications cover the same path, the priority is as 
follows (first listed is the highest priority, last listed is the lowest). 

• Timing Ignore (TIG) 

• FROM THRU TO 

• FROM TO 

• Specific OFFSET 

• Group OFFSET 

• Global OFFSET 

• PERIOD 

• ALLPATHS. 

• FROM THRU TO or FROM TO statements have a priority order 
that depends on the type of source and destination groups 
included in a statement. The priority is as follows (first listed is 
the highest priority, last listed is the lowest). 
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• Both the source group and Ihe destination group are user- 
defined groups 

• Either the source group or the destination group is a 
predefined group 

• Both the source group and the destination group are 
predefined groups 

• OFFSET constraints take precedence over more global constraints 
such as the ALLPATHS constraints. 

If two specific OFFSET constraints at the same level of prece¬ 
dence interact, an OFFSET with a register qualifier takes prece¬ 
dence over an OFFSET without a qualifier; if otherwise 
equivalent, the latter in the constraint file takes precedence. 

• Net delay and Net skew specifications are analyzed indepen¬ 
dently of path delay analysis and do not interfere with one 
another. 

Syntax Summary 

Tire following sections summarize the syntax for timing constraints. 

TNM Attributes 


Tire following table lists the syntax used when creating TNMs, which 
you enter directly on the primitive symbol, macro symbol, net, or 
driver pin. 


TNM Attribute Syntax 

Where Applied 

Schematic syntax: 

TMfcpredefined group identifier 

UCF syntax: 

INET 1 PIN INSTANCE) name THU*? identifier 

INET 1 PIN INSTANCE) mime TUU-predefined group identifier; 

Net. Symbol, Pin, 
Macro 
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TIMEGRP Attributes 


Tine following lable lusts the syntax used with the TIMEGRP 
primitive. 


Group Type 

TIMEGRP Attribute Syntax 

Combine 

Schematic syntax in TIMEGRP primitive: 
tiew_group*group 1 group2 | group3 .. .| 

UCF syntax: 

TIMEGRP neiv_group*groupI group! [ group! ...|; 

Exclude 

Schematic syntax in TIMEGRP primitive: 
new_groupmgroupl\group2 ...) except group3[ group4 ...] 

UCF syntax: 

TIMEGRP nezi'_grotip*groiipHgn)up2 .. .| except £n>up3| group4 ...|; 

Clock Edge 
(flip-flops) 

Schematic syntax in TIMEGRP primitive: 
iteip_£riwp=RISING group! 
itcir_£ri>H;i=FALLING group! 

UCF syntax: 

TIMEGRP neu'_group=RlS ING groupl; 

TIMEGRP neu<_group* FALLING groupI ; 

Gate Edge 
(latches) 

Schematic syntax in TIMEGRP primitive: 
ncir^wi/p-TRANSHI group! 
neicgroup-7RAHSL0 group! 

UCF syntax: 

TIMEGRP ireie.^r.Mi'sTRANSHI group]; 
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Group Type 

TIMEGRP Attribute Syntax 

Pattern 

Matching 

Schematic syntax in TIMEGRP primitive: 

iiew mm group~predefined m group (name ^qualifier 1 1 namejjualifier 2 ...)) 

UCF syntax: 

TIMEGRP new _gtoup*predefitu>d group (name qualifierl\ name qua lifter2 . 

1); 

N'et-specific 

OFFSET* 

Schematic syntax when attached to a net. 

OFFSET ■ ilN OUT! offset Jinte (i/nrls] (BEFORE 1 AFTER! elk name 
|TIMEGRP group name] 

UCF syntax; 

NET name OFFSET =iINIOOT| offset Jime [units] (BEFORE 1 AFTER 1 
elk name (TIMEGRP group name]; 

PCF syntax; 

COMP " iobjiame ” OFFSET - (INIOUT! offset time (unite | 
before 1 AFTER! COMP "elk job iiiimc" |TIMEGRP "group.name" 1; 
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TIMESPEC Attributes 


Tlio following table lists the syntax used for parameters that define 
TS attributes, which reside in the TIMESPEC primitive or appear in 
UCF or NCF files. 


Spec Type 

TS Attribute Syntax 

Basic 

From-To 

Schematic syntax in TIMESPEC primitive: 

TSiif=FROM source group TO dost group delay 

TSiif=FRCM source .group delay 

TSnf=TO dest.group delay 


UCF syntax: 

TIMESPEC TSiif=FROM source group TO desl .group delay, 

TIMESPEC TSii/-FROM source group delay; 

TIMESPEC TSiJ=TO dest.group delay; 

Ignore 

Schematic syntax in TIMESPEC primitive: 

TSli/= IGNORE 


UCF syntax: 

TIMESPEC TSfii* IGNORE; 

Through 

point 

Schematic syntax in TIMESPEC primitive: 

TSiJ=FRCM sourcejgroup THRU thru pointl THRU 
thru point] TO dest^group delay 

TSiif=FRCM source ggrotip THRU thru pointl THRU 
thru .point] delay 

TSiJ=THRU thru pei/tf| THRU thru point] TO dest group delay 


UCF syntax: 

TIMESPEC TS 11 /-FRCM source,group THRU thru point | THRU 
thru point] TO dest^roup delay; 

TIMESPEC TSii!-FROM source group THRU thru pointl THRU 
lhru_/vint] delay; 

TIMESPEC TS/if=THRU thru _pom([ THRU thru point] TO dest_group 
delay; 
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Spec Type 

TS Attribute Syntax 

Linked 

specification 

Schematic syntax in TIMESPEC primitive: 

TSji/=FROM source^group TO desl_group another TSid 
|* 1 /]nuniber 

TSh/=FROM source ^group another TSid 
|* 1 /]nuniber 

TSji/=TO dcst^group another TSid\* \ /\nmnber 


UCF syntax: 

TIMESPEC TS/i/=FROM source .group TO dest_group another TSid 
|* 1 /\number; 

TIMESPEC TSii/=FROM source group another TSid 
|* 1 /\nuntber; 

TIMESPEC TSn/=TO dest group another TSUI* 1 /jnumber; 

Clock period 

Schematic syntax in TIMESPEC primitive: 

TSid-PERIOD TNM .reference period (HIGH 1 LOW| [liigh_orJomJime\ 


UCF syntax: 

TIMESPEC TS/d-PERIOD TNM reference period (HIGHlLOWI 

orjou'jime ]; 

Derived 

clocks 

Schematic syntax in TIMESPEC primitive: 

TSiJ=PERIOD TNM reference another PERIOD identifier 
|/ 1 *lmrmMHIGH 1 LOW' [togfi. orjow.time] 


UCF syntax: 

TIMESPEC TSid-PERIOD TNM reference another PERIOD identifier 

1/ 1 *l/rumMHIGH 1 LOW} [/ii£/i orjowjime]; 
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Spec Type 

TS Attribute Syntax 

TS attribute 
priority 

normal Jimespec _syntax PRIORITY Integer 

Group 

OFFSETS 

Schematic syntax in T1.V1ESPEC primitive: 

TS iileittifier =TIMEGRP name OFFSET^ [IN OUT! offset Jime limits] 

1 BEFORE 1 AFTER, elk name |TIMEGRP group, name ) 


Tine UCF and PCF syntax do not require the TSnlentifier. 


UCF syntax: 

ITIMEGRP iMffie] OFFSET^jlN OUT! offset tune |l/m'fs) 

IBEFORE 1 AFTER! elk name |TIMEGRP group name]; 


PCF syntax: 

ITIMEGRP name] OFFSET^ |IK OUT! Offset time fun its] 

IBEFORE 1 AFTER! COMP elk Job name |TIMEGRP group name]; 


Tine following table lists additional attributes or constraints that are 
used in or affect TS attributes. 


Attribute Syntax 

Where 

Applied 

How Used 

Schematic syntax on net. pin, symbol, or macro: 
TPTHRU=iJiviff/ii’r 

UCF syntax: 

INET 1 PIN INSTANCE) name TPTHRU=identi/ier; 

Net. 

symbol, 

pin, 

macro 

In through point TS 
attribute 

Schematic syntax on net. pin, symbol, or macro: 

TP S YNC■ identifier 

UCF syntax: 

INET 1 PIN INSTANCE) name TPSYHC=identlfier; 

Net. 

symbol, 

pin, 

macro 

As group in TS attribute 
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Attribute Syntax 

Where 

Applied 

How Used 

Schematic syntax on net or pin: 

TIG 

TIG*identifiei 

UCF syntax: 

INET 1 PIN) mime TIG; 

INET 1 PIN) name TIG"identifier; 

Net. pin 

Prevents timing analysis 

TSiif.7iff/ii--=DR0P SPEC; (Constraints file only) 

N/A 

Prevents timing analysis 
for TSidentifier 


Other Constraints 

Tine following table lists additional timing constraints. 


Attribute Syntax 

Where Applied 

How Used 

Schematic syntax on net or pin: 

PERIOD period {HIGH 1 LOW| 

Vtigh_orJoip_linie\ 

UCF syntax: 

INET 1 PIN} mime PERIOD penal 

IHIGH 1 LOW' I high firjowjiim]; 

Nets, pins 

Specifies register 
clock period 
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Attribute Syntax 

Where Applied 

How Used 

Schematic syntax: 

MAXSKEW»<r/for«iW.> skew 

UCF syntax: 

NET name MHXSKEU=nlloit<abte .skeu<; 

FCF Syntax: 

INET 1 TIMEGRP ALLCLOCKNETS} l!i7l/lf 
HJiXSKEV-etloieiible skew; 

Nets, timegroups, 
ALLCLOCKNETS 

Specifies skew 
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Allribule Syntax 

Where Applied 

How Used 

Schematic syntax: 

MAXDELAY= path value (PRIORITY integer] 

UCF syntax: 

NET MCI MiTlMC MAXDELAY= fXItll value 
(PRIORITY HlJC«cr|; 

PCF syntax: 

TSidenlifier MAXDELAY path path value 
(PRIORITY /Mletjcr|; 

INET 1 TIMEGRP ALLCLOCKNETS} name 
MAXDEIAY= piilh value (PRIORITY integer]; 

PATH /Kith iiani-: MAXDELAYb piilh ;alue 
(PRIORITY Integer}; 

ALLPATHS MAXDELAY* 1*1 III mine 
(PRIORITY /Mfc«cr|; 

FROM group item THRU group .itenil... 
group Ileum MAXDELAY= path value 
(PRIORITY Hl/c^cr]; 

FROM group Hem THRU group itenil... 
group Jtemn TO group item MAXDELAY= 
l*ith value (PRIORITY integer}; 

THRU group itemI... group itenn TO 
group item MAXDELAY= path .value 
(PRIORITY integer}; 

Nets, Paths, 

FROM THRU, 
FROM THRU TO, 
THRU TO 

Specifies delay 
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The Logical Design Rule Check 


This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

• XC9500 

• XC9500XL 

This chapter describes the Logical Design Rule Check (DRC). The 
chapter contains the following sections. 

• The Logical DRC" 

• "The Logical DRC Tests" 

The Logical DRC 

The Logical DRC (Design Rule Check), is a series of tesLs run to verify 
the logical design in the NGD (Generic Database) file. The Logical 
DRC (aLso called the NGD DRC) performs device-independent 
checks; they do not depend on the FPGA to which you will 
eventually map the design. 
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Tine Logical DRC generates messages to show the status of the tests 
performed. Messages can be error messages (for conditions where the 
logic will not operate correctly) or warnings (for conditions when? the 
logic is incomplete). 

Tine Logical DRC runs automatically at these times. 

• At the end of NGDBuild, before NGDBuild writes out the NGD 
file. NGDBuild writes out the NGD file if DRC warnings are 
discovered, but does not write out an NGD file if DRC errors are 
discovered. 

• At the end of each netlist writer (NGD2ED1F. NGD2VER. or 
NGD2VHDL). before writing out the netlist file. Tine netlist 
writers do not perform the entire DRC; they only perform a 
subset of the DRC tests. A netlist writer writes out a netlist file 
even if DRC warnings or errors are discovered. 

The Logical DRC Tests 

Tine Logical DRC performs six types of checks. 

• Block check 

• Net check 

• Pad check 

• Clock buffer check 

• Name check 

• Primitive pin check 

Tine following sections describe these tests. 

The Block Check 

Tine block check verifies that each terminal symbol in the NGD 
hierarchy (that is, each symbol that is not resolved to any lower-level 
components) is an NGD primitive. A block check failure is treated as 
an error. As part of the block check, the DRC also checks user-defined 
properties on symbols and the values on the properties to make sure 
they are legal. 
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The Net Check 

Tile net check determines the number of NGD primitive output pins 
(drivers). Instate pins (drivers) and input pins (loads) on eacli signal 
in the design. If a signal does not have at least one driver (or one 
tristate driver) and at least one load, a warning is generated. An error 
is generated if a signal has multiple non-tristate drivers or any 
combination of tristate and non-tristate drivers. As part of the net 
check, the DRC also checks user-defined properties on signals and 
the values on the properties to make sure they are legal. 

The Pad Check 

The pad check verifies that each signal connected to pad primitives 
obeys the following rules. 

• If the PAD is an input pad. the signal to which it is connected can 
only be connected to these types of primitives. 

• A BUF primitive 

• A CKBUF primitive 

• A PULLUP primitive 

• A PULLDOWN primitive 

• BSCAN primitive 

Tine input signal can be attached to multiple primitives, but only 
one of each of the above types. For example, the signal can be 
connected to a BUF primitive, a CKBUF primitive, and a 
PULLUP primitive, but it cannot be connected to a BUF primitive 
and two CKBUF primitives. Also, the signal cannot be connected 
to both a PULLUP primitive and a PULLDOWN primitive. Any 
violation of the rules above results in an error, with the exception 
of signals attached to multiple pullups or pulldowns, which 
pnwduces a warning. A signal which is not attached to any of the 
above types of primitives also produces a warning. 

• If the PAD is an output pad. the signal it is attached to can only 
be connected to these primitive outputs. 

• A single BUF primitive output, or 

• A single TR1 primitive output, or 

• A single BSCAN primitive 
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In addition to 

• A single PULLUP primitive, or 

• A single PULLDOWN primitive 

Any other primitive output connections on the signal results in 
an error. 

If the condition above is met. the output PAD signal may also be 
connected to one CKBUF primitive input, one BUF primitive 
input, or both. 

• If the PAD is a bidirectional or unbonded pad. the signal it is 
attached to must obey the rules stated above for input and output 
pads. Any other primitive connections on the signal results in an 
error. Tire signal connected to the pad must be configured as both 
an input and an output signal, if it is not, you receive a warning. 

• If the signal attached to the pad has a connection to a top-level 
symbol of the design, that top-level symbol pin must have the 
same type as the pad pin, except that output pads can be 
associated with tristate top-level pins. A violation of this rule is a 
warning. 

• No signal can be connected to multiple pads (an error) or to 
multiple top-level pins (a warning). 

The Clock Buffer Check 

Tire clock buffer configuration check verifies that the output of each 
chick buffer primitive is connected to only inverter, flip-flop or latch 
primitive clock inputs, or other clock buffer inputs. Violations an? 
treated as warnings. 

The Name Check 

The name check verifies the uniqueness of names on NGD objects as 
defined below. The tests, and the messages reported by a violation of 
the tests, are as follows: 

• Pin names must be unique within a symbol. A violation is an 
error. 

• Instance names must be unique within the instance's position in 
the hierarchy (that is, a symbol cannot have two symbols with the 
same name under it). A violation is a warning. 
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• Signal names must be unique within the signal's hierarchical 
level (that is, if you push down into a symbol, you cannot have 
two signals with the same name). A violation is a warning. 

• Global signal names must be unique within the design. A 
violation is a warning. 

The Primitive Pin Check 

The primitive pin check verifies that certain pins on certain 
primitives an? connected to signals in the design. The check tests 
these pins on these NGD primitive types. 


NGD Primitive 

Pins Checked 

X TR1 

IN. OUT, and CTL 

X FF 

IN, OUT, and CLK 

X LATCH 

IN, OUT, and CLK 

X IPAD 

PAD 

X OPAD 

PAD 

X BPAD 

PAD 


If one of these pins is not connected to a signal, you receive a 
warning. 


Development System Reference Guide 


7-5 





Development System Reference Guide 


7-6 


Xili mx Development System 




Chapter 8 


MAP—The Technology Mapper 

This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

This chapter describes MAP. The chapter contains the following 
sections. 

• "MAP" 

• "MAP Syntax" 


• "The MAP Process" 

• "Register Ordering" 

• "Guided Mapping" 

• "Simulating Map Results" 

• "The MAP Report (MRP) File" 

• "Halting MAP" 
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MAP 

MAP maps a logical design lo a Xilinx FPGA. The inpul to mapping 
is an NGD file, which contains a logical description of the design in 
terms of both the hierarchical components used to develop the design 
and the lower level Xilinx primitives, and any number of NMC 
(macro library) files, each of which contains the definition of a 
physical macro. MAP first performs a logical DRC (Design Rule 
Check) on the design in the NGD file. MAP then maps the logic to the 
components (logic cells, I/O cells, and other components) in the 
target Xilinx FPGA. The output design is an NCD (Native Circuit 
Description) file - a physical representation of the design mapped to 
the components in the Xilinx FPGA. The NCD file can then be placed 
and routed. 

Tine flow through MAP is shown in the following figure. MAP can be 
invoked from the Design Manager/Flow - Engine graphical interface 
or from the UNIX or DOS command line. The Design Manager/Flow 
Engine is described in the Design Muiniger/Flow Engine Guide. This 
chapter describes running MAP from the UNIX or DOS command 
line. 



Figure 8-1 MAP 
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Note: For Virtex and Spartan2, MAP does not support guide files. 

MAP Syntax 

Tile following syntax maps your design. 

nap [op/ions] infile[ . ngd] \pcf_fi!e[ .pcf )| 

Op/iens tan be any number of the MAP options listed in the "MAP 
Options" section. They do not need to be listed in any particular 
order. Separate multiple options with spaces. 

lnfile\ . ngd| is the input NGD file. You do not have to enter the .ngd 
extension. 

Pcfjile\ .pcf | Ls the Physical Constraints File in PCF format. A 
constraints file name is optional on the command line, but if one is 
entered it must be entered after the input file name. You do not have 
to enter the .pcf extension. The constraints file name and its location 
are determined in this way. 

• If you do not specify a physical constraints file name on the 
command line, the physical constraints file has the same name a* 
the output file, with a .pcf extension. The file is placed in the 
output file's dime ton 1 . 

• If you specify a physical constraints file with no path specifier 
(for example, epu 1 . pcf instead of /home/designs/ 

epu 1 .pcf). the .pcf file is placed in the current working 

directory. 

• If you specify a physical constraints file name with a full path 
specifier (for example, /hocne/designs/cpu 1 .pcf). the 
physical constraints file is placed in the specified directory. 

• If the physical constraints file already exists, MAP reads the file, 
checks it for syntax errors, and overwrites the 
schematic-generated section of the file. MAP also checks the 
user-generated section for errors and corrects ermis by 
commenting out physical constraints in the file or by halting the 
operation. If no errors are found in the user-generated section, 
the section remains the same. 

For a discussion of the output file name and its location, see the "-o 
(Output File Name)" section. 
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MAP Files 

Tills section describes the MAP inpul and output tiles. 

Input Files 

MAP uses the following files as inputs. 

• NGD file—Native Generic Database file. This file contains a 
logical description of the design expressed both in terms of the 
hierarchy used when the design was first created and in terms of 
lower-level Xilinx primitives to which the hierarchy resolves. The 
file also contains all of the constraints applied to the design 
during design entry or entered in a UCF (User Constraints File). 
The NGD file is created by NGDBuild. 

• NMC files—Macro library files. An NMC file contains the 
definition of a physical macro. When there are macro instances in 
the NGD design file, NMC files are used to define the macro 
instances. There is one NMC file for each type of macro in the 
design file. 

• Guide NCD file—An optional input file generated from a 
previous MAP run. An NCD file contains a physical description 
of the design in terms of the components in the target Xilinx 
device. A guide NCD file is an output NCD file from a previous 
MAP run that is used as an input to guide a later MAP run. 

Note: Virtex and Spartan2 do not support guide files. 

• MFP—Map Floorplanner File, which is generated by the 
Floorplanner, specified as an input file with the -fp option. The 
MFP file is essentially used as a guide file for mapping. To create 
a Map Floorplanner File, you must first have generated an NGD 
file and a mapped NCD file. When you have run MAP to 
generate an NCD file, you can open the mapped NCD file in the 
Floorplanner, modify the placement of components, and then 
generate an MFP file. You can then use the MFP file as an input 
file with the -fp map option. The MFP file is only created for the 
XC4000, Spartan/E/2, and Virtex architectures. 
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• MDF file—MAP Directive File. The MDF is an optional input file 
used for guided mapping. The MDF file describes how logic was 
decomposed when the guide design was mapped. MAP uses the 
hints in the MDF as a guide for logic decomposition in the guided 
mapping run. 

Output Files 

Output from MAP consists of the following files. 

• NCD file—Native Circuit Description. A physical description of 
the design in terms of the components in the target Xilinx device. 
For a discussion of the output NCD file name and its location, see 
the "-o (Output File Name)" section. 

• PCF (Physical Constraints) file—an ASCII text file containing the 
constraints specified during design entry expressed in terms of 
physical elements. The physical constraints in the PCF file are 
expressed in Xilinx's constraint language. This file is described in 
"The Physical Constraints (PCF) File" chapter. 

MAP either creates a PCF file if none exists or rewrites an existing 
file by overwriting the schematic-generated section of the file 
(between the statements SCHEMATIC START and SCHEMATIC 
END). For an existing physical constraints file. MAP also checks 
the user-generated section for syntax errors, and signals errors by 
halting the operation. If no errors are found in the user-generated 
section, the section is unchanged. 

• NGM file—a binary design file containing all of the data in the 
input NGD file as well as information on the physical design 
produced by the mapping. The NGM file is used to correlate the 
back-annotated design netlist to the structure and naming of the 
source design. 

• MRP (MAP report) file—a file containing information about the 
MAP command run. The MRP file lists any errors and warnings 
found in the design, lists design attributes specified, details on 
how the design was mapped (for example, the logic that was 
removed or added and how signals and symbols in the logical 
design were mapped into signals and components in the physical 
design). The file also supplies statistics about component usage 
in the mapped design. See "The MAP Report (MRP) File" section 
for more details. 
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• MDF (MAP Directive File)—a file describing how logic was 
decomposed when the design was mapped. In guided mapping, 
MAP uses the hints in the MDF as a guide for logic 
decomposition. 

The MRP, MDF and NGM files produced by a MAP run all have the 
same name as the output file, with the appropriate extension. If the 
MRP, MDF or NGM files already exist, they are overwritten by the 
new files. 

MAP Options 


Tlie following table illustrates which architectures can be used with 
each option. 

Table 8-1 Map Options and Architectures 


Options 

Architectures 

-b 

Spartan. xc4000e/l 

< 

Spartan. SpartanXL. Spartan2. xc3000a/l, xc3100/a/l, 
xotOOOe/ex/1/xl/xla/xv, xc52(X), Virtex 

-cm 

Spartan. SpartanXL. Spartan2, Virtex, xc3000a/l, 
xc3100/a/I, xc4000e/ex/l/xl/xla/xv, xc52l)0 

-d 

xc3000a/l, xc31(XXi/l 

-detail 

all FPGA architectures 

-f 

Spartan. SpartanXL. Spartan2. Virtex, xc3000a/l, 
xc310D/a/I, xc4000e/ex/l/xl/xla/xv, xc5200 

-fp 

Spartan, SpartanXL, Spartan2, xc4000e/ex/l/xl/xla/ 
xv, xc5200, Virtex 

-8' 

Spartan, SpartanXL. xc3000a/l, xc3100/a/l, xc4<XXW 
ex/l/xl/xla/xv, xc5200 

-gm 

Spartan, SpartanXL. xc3000a/l, xc3100/a/l, xc4000e/ 
ex/ 1 /xl/xla/xv, xc5200 

-ir 

Spartan, SpartanXL, Spartan2, Virtex, xc4lXX)e/ex/l/ 
xl/xla/xv, xc5200 

-k 

Spartan. SpartanXL. Spartan2. Virtex, xc4tXX>e/ex/l/ 
xl/xla/xv, xc5200 

-I 

Spartan. SpartanXL. Spartan2. Virtex, xc4(XXWex/l/ 
xl/xla/xv, xc5200 
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Table 8-1 Map Options and Architectures 


Options 

Architectures 

-o 

All architectures 

-oe 

Spartan. SpartanXL. xc300Qa/l, xc3100/a/l, xc4000e/ 
ex/l/xl/xla/xv, xc5200 

-os 

Spartan. SpartanXL. xc3000a/l, xc3100/a/l, xc4000e/ 
ex/l/xl/xla/xv, xc5200 

-p 

Spartan. SpartanXL. Spartan2. Virlex. xc30(X>a/l, 
xc310D/a/l, xc4000e/ex/l/xl/xla/xv, xc5200 

-pr 

Spartan. SpartanXL. Spartan2. Virlex. xc3000a/l, 
xc310D/a/l, xc4000e/ex/l/xl/xla/xv 

-r 

Spartan. SpartanXL. Spartan2. xc3000a/l. xc3100/a/l, 
xc4000e/ex/l/xl/xla/xv, Virtex 

-u 

Spartan. SpartanXL. Spartan2. Virlex, xc3fl(X»a/l, 
xc3100/a/l, xc4000e /ex/l/xl/xla/xv, xc5200 


Tine following subsections describe each command line option and its 
effect on the behavior of MAP. 


-b (Convert Clock Buffers—XC4000E/L and Spartan 
Only) 

Note: This option does not apply to the Spartan2 or SpartanXL archi¬ 
tecture. 

Tine -b option replaces GCLKs and ACLKs (primary and secondary 
clocks) with a generic clock buffer (CKBUF) prior to mapping. This 
option is useful when you are mapping an XNF netlist created in the 
Synopsys environment where all clocks are mapped to BUFGP 
(primary clock buffers) and secondary clocks are not used. The -b 
option gives MAP the greatest amount of latitude in choosing the 
clock assignments. 

Note: MAP does not override the LOC= constraint. 
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-c (Pack CLBs) 

-c \packfaclor] 

Tine -c option determines the degree to which CLBs are packed when 
the design is mapped. The valid range of values for the packfactor is 0- 
100 . 

Tine t<ackfactor values ranging from 1 to 100 roughly specify the 
percentage of CLBs available in a target device for packing your 
designs logic. 

A packfactor of 100 means that all CLBs in a target part are available 
for design logic. A packfactor of 100 results in minimum packing 
density, while a packfactor of 1 represents maximum packing density. 
Specifying a lower packfactor results in a denser design, but the design 
may then be more difficult to place and route. 

Tine -c 0 option specifies that only ‘related* logic (that is, logic 
having signals in common) should be packed into a single CLB. 
Specifying -c 0 yields the least densely packed design. 

For values of -c from 1 to 100, MAP merges unrelated logic into the 
same CLB only if the design requires more resources than are 
available in the target device (an "overmapped" design). If there are 
wore resources available in the target device than are needed by your 
design, the number of CLBs utilized when -c 100 is specified may 
equal the number required when -c 0 is specified. 

Note: The -c 1 setting should only used to determine the maximum 
density (minimum area) to which a design can be packed; it should 
almost never be used in the actual implementation of a design. 
Designs packed to this maximum density generally have longer run 
times, severe routing congestion problems in PAR. and poor design 
performance. 

The default packfactor (the value if you do not specify a -c option, or 
enter a -c option without a podfactor) is 97% for the XC4000E 
architecture and 100% for all other XC4000 architectures, Virtex, and 
Spartan/XL/2. 

Processing a design with the -c 0 option is a good way to get a first 
estimate of the number of CLBs required by your design. 
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-cm (Cover Mode) 

-cm [area I speed I balanced! 

Tine -cm option specifies tine criteria used during the "cover" phase of 
MAP. In the "cover” phase. MAP assigns the logic to CLB function 
generators (LUTs). 

• Tine area setting makes reducing the number of LUTs (and 
therefore the number of CLBs) the highest priority. 

• Tine speed setting makes reducing the number of lewis of LUTS 
(the number of LUTs a path passes through) the highest priority. 
This setting makes it easiest to achieve your tinning constraints 
after the design is placed and routed. For most designs there is a 
small increase in the number of LUTs (compared to the area 
setting), but in some cases the increase may be large. 

• Tine balanced setting balances the two priorities—reducing the 
number of LLTs and reducing the number of levels of LUTs. It 
produces result' similar to the speed setting but avoids the 
possibility of a large increase in the number of LUTs. 

Tine default setting for the -cm option is area (cover for minimum 
number of LUTs). 

-d (Use Dl Pin—XC3000 Architectures Only) 

If you specify this option, MAP can use the DI (Direct Input) pin of 
each CLB in the device for the XC3000A, XC3000L, XC3100A and 
XC3100L architectures. If you use this pin, the setup time 
requirement for each CLB flip-flop is reduced, but the DI pin has a 
hold time requirement (which none of the other CLB logic input pins 
has). Using the DI pin results in a denser design, but the design may 
then be more difficult to place and route. Even if you specify the -d 
option, MAP tries to minimize the use of the DI pin. 

-detail (Write Out Detailed MAP Report) 

Tills option writes out a detailed MAP report. The option replaces the 
MAP REPORT DETAIL environment variable. 


8-9 


Detvlopinenl System Reference Guide 




Dtveiopmenl System Reference Guide 


-f (Execute Commands File) 

-f command Jtle 

Tile -f option executes the command line arguments in the specified 
count land. file. For mom information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-fp (Floorplanner) 

-fp filename . mfp 

The -fp option requires the specification of an existing MFP file 
created by the Flooiplanner. The MFP file is essentially used as a 
guide file for mapping. 

Tine MFP file is created in the Floorplanner from a previously 
mapped \'CD file. If you use the -fp option, you cannot use the guide 
file option (-gf). 

Tine -fp option can be used with the XC4000/E/L, XC4000EX/XL/ 
XL A/XV, Spartan/XL/2, and Virtex architectures. 

For more information about the Floorplanner, see the Floorplanner 
Reference/User Guide. 

-gf (Guide NCD File) 

-gf gtiidefile 

Tine -gf option specifies the name of an existing NCD file (from a 
previous MAP run) to be used as a guide for the current MAP run. 
For a description of guided mapping, see the "Guided Mapping" 
section. 

This option does not apply to Virtex or Spartan2. 
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-gm (Guide Mode) 

-gtn (exact I leverage] 

Tlie -gm option specifies the form of guided mapping to be used. 

In the EXACT mode the mapping in the guide file is followed exactly. 
In the LEVERAGE mode, the guide design is used as a starting point 
for mapping but. in cases where the guided design tools cannot find 
matches between net and block names in the input and guide 
designs, or your constraints rule out any matches, the logic is not 
guided. 

For a description of guided mapping, see the "Guided Mapping" 
section. 

This option does not apply to Virtex or Spartan! 

-ir (Do Not Use RLOCs to Generate RPMs) 

If you enter the -ir option. MAP uses RLOC constraints to group 
logic within CLBs, but does not use the constraints to generate RP.Vls 
(Relationally Placed Macros) controlling the relative placement of 
CLBs. Stated another way, the RLOCs are not used to control the 
relative placement of the CLBs with respect to each other. 

For the XC4000 and Spartan architectures, the -ir option has an 
additional behavior; the RLOC constraint that cannot be met is 
ignored and the mapper will continue processing the design. A 
warning is generated for each RLOC that is ignored. The resulting 
mapped design is a valid design. 

Tills option does not apply to the XC3000 architecture. 

-k (Map to Input Functions) 

Tlie syntax for Virtex, Spartan2 architectures follows: 

-k |4 IS I6| 

For Virtex and Spartan2 architectures, you can specify the maximum 
size function that is covered. The default is 4. For compatibility with 
M1.5, use -k 4. Covering to 5 or 6 input functions will result in the use 
of F5MUX or F6MUX. 
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For theXC4000and XC520O architectures, only -k is specified (not 4,5 
or 6). If the -k option is specified, logic functions of five inputs aie 
mapped into a single CLB (if possible). To perform this mapping, all 
three of the function generators in the CLB may be used 

By mapping input functions into single CLBs. the -k option may 
produce a mapping with fewer levels of logic, thus eliminating a 
number of CLB-to-CLB delays. On the other hand, using the -k 
option may prevent logic from being packed into CLBs in a way that 
minimizes CLB utilization. 

Tire -k option does not apply to the XC3000 architecture. 

-I (No logic replication) 

If you do not specify the -1 option. MAP can perform logic 
replication, a logic optimization in which the program takes a single 
driver driving multiple loads and maps it as multiple components, 
each driving a single load (see the following figure). Logic replication 
results in a mapping that often makes it easier to meet your timing 
requirements, since some delays can be eliminated on critical nets. 

This option does not apply to the XC3000 and XC52U0 architectures. 
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-o (Output File Name) 

-o oulfllel. ncd| 

Specifies Ihe name of Ihe output NCD file for the design. The .ncd 
extension is optional. The output file name and its location are 
deteimined in this way. 

• If you do not specify an output file name with the -o option, the 
output file has the same name as the input file, with an .ncd 
extension. The file is placed in the input file’s directory. 

• If you specify an output file name with no path specifier (for 
example, epu dec. ncd instead of/home/designs/ 

epu dec. ncd). the NCD file is placed in the current working 
directory. 

• If you specify an output file name with a full path specifier (for 
example, /home/deaigna/cpu dec. ncd). the output file is 
placed in the specified directory. 

If the output file already exists, it is overwritten with the new NCD 
file. You do not receive a warning when the file is overwritten. 

-oe (Logic Optimization Effort) 

-oe Inormal I high} 

The -oe option specifies the effort MAP uses when performing logic 
optimization. In the high setting. MAP exerts a greater effort to 
optimize combinatorial logic, but the mapping takes longer to 
complete. The high setting must be used if the input to the MAP is 
not optimized, for example, a design created in XABEL. 

For Ihe -oe option to apply, the -os (logic optimization style) option 
must be enabled, that is, -os must have a setting other than none. 

If logic optimization is specified by the -os option, the default setting 
for Ihe -oe option is normal. 

See the following ’’-os (Logic Optimization Style)” section for 
guidelines on when to use logic optimization. 

This option does not apply to Virtex or Spai tan2. 
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-os (Logic Optimization Style) 

-os lacea I speed I balanced! 

Logic optimization in the context of MAP refers to FPGA-specific 4- 
input lookup optimization by the OPT1X optimizer. 

Tine -os option specifies what type of logic optimization MAP 
performs. 

• Tine area setting optimizes combinatorial logic in a way that 
uses the minimum number of logic cell function generators 
(LUTs). This setting minimizes the amount of device area taken 
up when the design is placed and routed. 

• Tine speed setting optimizes in a way that makes it easiest to 
achieve your tinning constraints after the design is placed and 
routed, even if more function generators must be used. 

• Tine balanced setting gives you the optimum combination of 
area and speed. 

Tine default setting for the -os option disables logic optimization—no 
optimization is performed. You may want to avoid performing logic 
optimization in the following cases. 

• Your design has a beady been optimized (for example, a design 
created in the Synopsys toolset). If the input to MAP has alieady 
been optimized (including FPGA-specifie 4-input LUT optimiza¬ 
tion), the MAP results with the -os option enabled may be worse 
than without the option. 

• Your design has been entered as a schematic using Xilinx Unified 
Library components. In this case, the MAP results with the -os 
option enabled may be worse than without the option. 

• You want to make sure you can perform back-annotation on any 
of the logic in your original design. Optimization may make 
some of the logic unavailable for back-annotation. 
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Note: After combinatorial logic optimization has been performed, 
you lose the correlation between signal names in the NCD file and 
signal names in the original design. User signal names are not 
preserved within optimized combinatorial networks. This affects 
back-annotation and also results in a reduction in the amount of 
guided mapping and guided placement and routing that can be 
performed. However, signals connected to pads or to the outputs of 
tbufs, flip-flops, latches, and RAMS are preserved for back- 
annotation. 

This option does not apply to Virtex or Spartan2. 

-p (Xilinx Part Number) 

-p part 

Specifies the Xilinx part number for the device. The syntax for the -p 
option is described in the "Part Numbers in Commands" section of 
the "Introduction" chapter. Examples of purl entries are XC4003E- 
PC84. and XC4028EX-HQ240-3. 

If you do not specify a part number using the -p option, MAP selects 
the part specified in the input NGD file. If the information in the 
input NCD file does not specify a complete device and package, you 
must enter a device and package specification using the -p option. 
MAP supplies a default speed value, if necessary. 

Note: Tlie architecture you specify with the -p option must match the 
architecture specified within the input NGD file. 

You may have chosen this architecture when you ran NGDBuild or 
during an earlier step in the design entry process (for example, you 
may have specified the architecture as an attribute within a 
schematic, or specified it as an option to a netlist reader). If the 
architecture does not match, you have to run NGDBuild again and 
specify the desired architecture. 

Note: You can only enter a part number or device name from a 
device library you have installed on your system. For example, if you 
have not installed the 4006E device library, you cannot create a 
design using the 4006E-PC84 part. 
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-pr (Pack Registers in I/O) 

-pr |i I o I b[ 

When .MAP runs without the -pr option. MAP can only place flip- 
flops or latches within an I/O cell if your design entry method 
specifies that these components are to be placed within I/O cells. For 
example, if you create a schematic using IFDX (Input D Flip-Flop) or 
OFDX (Output D Flip-Flop) design elements, the physical 
components corresponding to these design elements must be placed 
in I/O cells. The -pr option specifies that flip-flops or latches may be 
packed into input registers (i selection), output registers (o 
selection), or both (b selection) even if the components have not been 
specified in this way. This option does not apply to the XC52O0 
architecture. 

-r (No Register Ordering) 

Tine -r option disables register ordering. If you specify this option, 
register bit names are ignored when registers are mapped, and the 
bits are not mapped in any special older. If you do not specify this 
option, MAP looks at the register bit names for similarities and tries 
to map register bits in an ordered manner (called "register 
ordering"). For a description of register ordering, see the “Register 
Ordering" section. 

Note: For Virtex. If you are migrating from an M1.5 design to a 2-1 i 
design, you must use the -r option to maintain the behavior of the 
Ml.5 design. 

This option does not apply to the XC5200 architecture. 

-u (Do Not Remove Unused Logic) 

If -u is specified, MAP maps unused components and nets in the 
input design and includes them as part of the output design. If -u is 
not specified. MAP eliminates unused components and nets from the 
design before mapping. 

Tine -u option is helpful if you want to run a preliminary mapping on 
an unfinished design, possibly to see how many components the 
mapped design uses. By specifying -u, you are assured that all of the 
design's logic (even logic that is part of incomplete nets) is nnapped. 
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The MAP Process 

To map a design. MAP performs these steps. 

1. Choose the target Xilinx device, package, and speed. MAP selects 
a part in this way. 

• If a part is specified on the MAP command line, this is the 
part used. 

• If the command line does not specify a part, MAP selects the 
part specified in the input NGD file. If the information in the 
input NGD file does not specify a complete architecture, 
device, and package, you receive an error message and MAP 
does not continue. MAP supplies a default speed if neces¬ 
sary. 

2. Read the information in the input design file. 

3. Perform a Logical DRC (Design Rule Cheek) on the input design. 
If any DRC errors are detected, the MAP run is aborted. If any 
DRC warnings are detected, the warnings an? reported, but the 
MAP run continues. Tire Logical DRC (also called the NGD DRC) 
is described in "The Logical Design Rule Check" chapter. 

Note: Step 3 is skipped if the NGDBuild DRC was successful. 

4. Assign the device global clock buffers (if possible). 

5. Remove unused logic. All unused components and nets are 
removed, unless these conditions exist. 

• A Xilinx S (Save) constraint lias been placed on a net during 
design entry. If an unused net has an S constraint, the net and 
all used logic connected to the net (as drivers or loads) is 
retained. All unused logic connected to the net is deleted. 

For a more complete description of the S constraint, see the 
"Attributes, Constraints, and Carry Logic” chapter of the 
Libraries Guide. 

• The -u option was specified on the MAP command line. If 
this option is specified, all unused logic is kept in the design. 

6. Map pads and their associated logic into lOBs. 
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7. Map the logic into Xilinx components (IOBs. CLBs, etc.). If any 
Xilinx mapping control symbols appear in the design hierarchy 
of the input file (for example, FMAP or HMAP symbols targeted 
to an XC-UKK1EX device). MAP uses the existing mapping of these 
components in preference to remapping them. The mapping is 
influenced by various constraints: these constraints aie described 
in the "Attributes, Constraints, and Carry Logic" chapter of the 
Libraries Guide. 

8. Update the information received from the input NGD file and 
write this updated information into an NGM file. This NGM file 
contains both logical information about the design and physical 
information about how the design was mapped. The NGM file is 
used only for back-annotation. 

9. Create a physical constraints |PCF) file. This is a text file 
containing any constraints specified during design entry. If no 
constraints were specified during design entry, an empty file is 
created so that you can enter constraints directly into the file 
using a text editor or indirectly througli the FPGA Editor. 

MAP either creates a PCF file if none exists or rewrites an existing 
file by overwriting the schematic-generated section of the file 
(between the statements SCHEMATIC START and SCHEMATIC 
END). For an existing constraints file, MAP also checks the 
user-generated section and may either comment out constraints 
with errors or halt the program. If no errors are found in the user¬ 
generated section, the section remains the same. 

10. Create an MDF file, which describes how logic was decomposed 
when the design was mapped. The MDF file is used for guided 
mapping. 

Tills step does not apply to Virtex or Spartan2. 

11. Run a physical Design Rule Check (DRC) on the mapped design. 
If DRC errors are found, MAP does not write an NCD file. 

12. Create an NCD file, which represents the physical design. The 
NCD file describes the design in teims of Xilinx components— 
CLBs. IOBs, etc. 

13. Write a MAP report (MRP) file, which lists any errors or warn¬ 
ings found in the design, details how the design was mapped, 
and supplies statistics about component usage in the mapped 
design. 
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Register Ordering 

When you map a design containing registers, the MAP software can 
optimize the way the registers are grouped into CLRs (slices for 
Virtex or Spartan2—them am two slices per CLB). This optimized 
mapping is called "register ordering." 

A CLB (Virtex or Spartan2 slice) has two flip-flops, so two register 
bits can be mapped into one CLB. For PAR (Place And Route) to place 
a register in the most effective way, you often want as many pairs of 
contiguous bits as possible to be mapped together into the same CLBs 
(for example, bit 0 and bit 1 together in one CLB, bit 2 and bit 3 in 
another). 

MAP pairs register bits (performing "rngister ordering") if it can 
mcognize that a series of flip-flops comprise a register. When you 
create your design, you can name register bits in a way that ensures 
they are mapped using register ordering. 

Note: MAP decs not perform register ordering on any flip-flops which 
have BLKNM, LOC, or RLOC properties attached to them. The 
BLKNM. LOC. and RLOC properties define how blocks are to be 
mapped, and these properties override register ordering. 

To be recognized as a candidate for register ordering, the flip-flops 
must have these characteristics. 

• Tire flip-flops must slrare a common clock signal and common 
control signals (for example. Reset and Clock Enable). 

• Tire flip-flop output signals must all be named according to this 
convention. 

• Output signal names must begin with a common root 
containing at least one alphabetic character. 

• Tire names must end with numeric characters or with 
numeric characters surrounded by parentheses ("(" and ")" 
), angle brackets ( "<” and ">” ), or square brackets ("[" and 

T >• 

For example, acceptable output signal names for register 
ordering are as follows. 
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datal 

addr(04) 

bus<l> 

dat a 2 

addr< 08 > 

bus<2> 

data 3 

addr( 12 ) 

bus<3> 

dat a 4 

addr( 16 ) 

bus<4> 



bus<5> 

If a series 

of flip-flops is 

recognized as a candidate for register 


ordering, they are paired in CL Its in sequential numerical order. For 
example, in the first set of names shown above, datal and data 2 , are 
paired in one CLB, while dala3 and data4 are paired in another. 

In the example below, no register ordering is performed, since the 
root names for the signals are not identical. 

dataOl 

addr 02 

atod03 

dtoa04 

Note: In the OrCAD 'schematic capture program, an underbar (_) 
and a sheet number are appended to each output signal name (for 
example, dataOl 1 or addl5_ 12). In order to allow register ordering 
on designs developed using the OrCAD tools, MAP checks each 
signal name to see if it ends with an underbar followed by numeric 
characters. 

When it finds a signal with this type of name. MAP ignores the 
undeibar and the numeric characters when it considers the signal for 
register ordering. For example, if signals are named data(X) 1 and 
dataOl .2. MAP considers them as dataOO and dataOl for purposes of 
register ordering. These two signals are mapped to the same CLB. 
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Two extra notes: 

• MAP does not change signal names when it checks for 
underbars—it only ignores the underbar and the number when it 
checks to see if the signal is a candidate for register ordering. 

• Because of the way signals are checked, make sure you don't use 
an underbar as your bus delimiter. If you name a bus signal 
dataO 01 and a non-bus signal datal, MAP sees them as dataO 
and datal and register orders them even though you do not want 
them register ordered. 

When you run the MAP command the default setting performs 
register ordering. If you specify the -r option when you run the 
command, the software does not perform register ordering and maps 
the register bits as if they were unrelated. 

Guided Mapping 

In guided mapping, an existing NCD is used to guide the current 
MAP run. The guide file may be from any stage of implementation: 
unplaced or placed, unrouted or routed. 

Virtex and Spartan2 do not support guided mapping. 

The following figure shows the flow used when you perform guided 
mapping. 
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First MAP Run Second MAP Run 



Figure 8-3 Guided Mapping 

In the EXACT mode the mapping in Ihe guide tile is followed exactly. 
Any logic in the input NGD file that matches logic mapped into the 
physical components of the N'CD guide file is implemented exactly as 
in the guide file. Mapping (including signal to pin assignments), 
placement and routing am all identical. Logic that is not matched to 
any guide component is mapped by a subsequent mapping step. 

If there is a match in EXACT mode, but your constraints would 
conflict with the mapping in the guide file component, an error is 
posted. If an error is posted, you can modify the constraints to 
eliminate conflicts, change to the LEVERAGE guide mode (which is 
less restrictive), modify the logical design changes to avoid conflicts, 
or abandon using guided design. 

In the LEVERAGE mode, the guide design is used as a starting point 
in order to speed up the design process. However, in cases where the 
guided design tools cannot find matches or your constraints rule out 
any matches, the logic Ls not guided. 
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Whenever the guide design conflicts with the your mapping, 
placement or routing constraints, the guide is ignored and your 
constraints are followed. 

Since the LEVERAGE mode only uses the guide design as a starting 
point for mapping, MAP may subsequently choose to alter the 
mapping to improve the speed or density of the implementation (for 
example. MAP may choose to collapse additional gates into a guided 
CLB). 

Note: For Verilog* or VHDL netlist input designs, re-synthesizing 
modules typically cause signal and instance names in the resulting 
netlist to be significantly different from the netlist obtained in earlier 
synthesis runs. This occurs even if the source level Verilog or VHDL 
code only contains a small change. Because guided mapping depends 
on signal and component names, synthesis designs often have a low 
'match rate" when guided. Therefore, guided mapping is not 
recommended for most synthesis-based designs, although there may 
be cases where it could be a successful alternative technique. 

Simulating Map Results 

When simulating from NGM files, you are not simulating a mapped 
result, that is, you are simulating the logical circuit description. 
Simulating from the NCD file actually simulates the physical circuit 
description. 

MAP may generate an error that is not detected in the Kick-annotated 
simulation netlist. For example, you may run the following command 
after running MAP to generate the backannotated simulation netlist. 

ngdanno napped, ned mapped, ngtn -o mapped, nga 

This command creates a back-annotated simulation netlist using the 
logical-to-physical cross-reference file named mapped.ngm. This 
cross-reference file contains information about the logical design 
netlist which means that the back-annotated simulation netlist 
(mapped.nga) is actually a Kick-annotated version of the logical 
design. However, if MAP makes a physical error, for example, 
implements an Active Low function for an Active High function, this 
error will not be detected in the mapped.nga file which means that 
the error will not show up in the simulation. 

Consider the following logical circuit generated by NGBuild from an 
input design file. 
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A'B *C•D 



X0549 

Figure 8-4 Logical Circuit Representation 

Note the Boolean output from the combinatorial logic. Suppose that 
after running MAP for the preceding circuit, you obtain the following 
result. 
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Figure 8-5 CLB Configuration 
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Note that MAP has generated an active low |C) instead of an active 
high (C). Therefore, the Boolean output for the combinatorial logic is 
incorrect. When you run NGDAnno using the mapped.ngm file 
(ngdanno mapped.ncd mapped.ngm -o mapped.nga), you will not 
detect this logical error because the delays are back-annotated to the 
correct logical design not to the physical design. 

One way to detect the error is by running the NGDAnno command 
without using the mapped.ngm cross-reference file. 

ngdanno mapped.ncd -o mapped.nga 

Then physical simulations using the mapped.nga file will normally 
detect a physical error. However, even though, an error is detected, 
the specific type of error is not easily recognisable. You can use the 
FPGA Editor to try to pinpoint the error or call Xilinx Customer 
Support. It is also possible that the physical simulation is reporting an 
error that does not exist, that is, the CLB configuration is correct. In 
that instance, you can use the FPGA Editor to determine if the CLB is 
correctly modelled. 

Lastly, if both the logical and physical simulations do not discover 
existing errors, you may need to use more lest vectors in the 
simulations. 

The MAP Report (MRP) File 

Tire MAP report (MRP) file Is an ASCII (text) file containing 
information about the MAP command run. Although detailed 
information varies depending upon the device to which you have 
mapped, the format of the file is the same regardless of the device 
used. 

Note: The MRP file is formatted for viewing in a monospace (non¬ 
proportional) font. If the text editor you use for viewing the report 
uses a proportional font, the columns in the report do not line up 
correctly. 

A sample MRP file is shown below. This is an abbreviated file—most 
MAP report files are considerably larger than the one shown below. 

Tile report file is divided into a number of sections. Sections appear 
in the report file even if they are empty (that is. even if there are no 
messages that apply to them). 

These are the sections in the MAP report file. 
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• Design Information—Shows your MAP command, line, the 
device to which the design has been mapped, and when the 
mapping was performed. 

• Design Summary—Summarizes the mapper run. showing the 
number of errors and warnings, and how many of the resources 
in the target device are used by the mapped design. 

• Table of Contents—Lists the remaining sections of the MAP 
report. 

• Errors (Section 1)—Shows any errors generated as a result of the 
following. 

• Errois associated with the logical DRC tests performed at the 
beginning of the mapper run. These errors do not depend on 
the device to which you are mapping. 

• Errors the mapper discovers (for example, a pad is not 
connected to any logic, or a bidirectional pad is placed in the 
design but signals only pass in one direction through the 
pad). These errors may depend on the device to which you 
are mapping. 

• Errois associated with the physical DRC run on the mapped 
design. 

• Warnings (Section 2)—Shows any warnings generated as a result 
of the following. 

• Warnings associated with the logical DRC tests performed at 
the beginning of the mapper run. These warnings do not 
depend on the device to which you are mapping. 

• Warnings the mapper discovers. These warnings may 
depend on the device to which you are mapping. 

• Warnings associated with the physical DRC run on the 
mapped design. 

• Design Attributes (Section 3)—Shows any attributes (properties) 
specified when the design was created. Some of these attributes 
also appear as physical constraints in the physical constraints file 
(PCF) produced by the mapper run. 

• Removed Logic Summary (Section 4>—Summarizes the number 
of blocks and signals removed from the design. The section 
reports on these kinds of removed logic. 
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• Blocks trimmed—A "trimmed" block is a block removed 
because it is along a path that has no driver or no load. 
Trimming is recursive; that is, it Block A becomes 
unnecessary because logic to which it is connected has been 
trimmed, then Block A is also trimmed. 

• Blocks removed—A "removed" block is removed because it 
can be eliminated without changing the operation of the 
design. Removal is recursive; that is, if Block A becomes 
unnecessary because logic to which it is connected has been 
removed, then Block A is also removed. 

• Blocks optimized—An "optimized" block is a block removed 
because its output remains constant regardless of the state of 
the inputs (for example, an AND gate with one input tied to 
ground). Logic generating an input to this optimized block 
(and to no other blocks) is also removed, and appears in this 
section. 

• Signals removed—Signals that were removed because they 
were attached only to removed blocks. 

• Signals merged—A signal is merged when two signals are 
combined because a component separating them was 
removed. 

• Removed Logic (Section 5)—Describes in detail all logic (design 
components and nets) removed from the input \'GD file when 
the design was mapped. The preceding description of Section 4 
defines the types of logic removed. More generally, logic may be 
removed because 

• A design uses only part of the logic in a library macro. 

• Tine design has been mapped even though it is not yet 
complete. 

• Tine mapper has optimized the design logic. 

• Unused logic has been created in error during schematic 
entry. 

This section also indicates which nets were merged (that is. two 
nets were combined when a component separating them was 
removed). 
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In this section, if tile removal of a signal or symbol results in the 
subsequent removal of an additional signal or symbol, the line 
describing the subsequent removal is indented. This indentation 
is repeated as a chain of related logic is removed. To quickly 
locate the cause for the removal of a chain of logic, look above the 
entry in which you are interested and locate the top-level line, 
which is not indented. 

• Added Logic (Section 6)—Describes any logic that was added to 
the design by the mapper. For example, logic is added when a 
design contains global reset buffers but the device to which you 
are mapping does not have global reset buffers. The mapper adds 
the necessary logic to perform the global reset function. 

• Expanded Logic (Section 7)—If enabled, describes the mapping 
of logic that has been added to the database to resolve certain 
design blocks (for example, LogiBLOX modules). 

By default this section is empty, since the section may contain 
thousands of lines and the information is not needed by the 
majority of users. To create this section, select the -detail option. 

• Signal Cross Reference (Section 8>— If enabled, shows where nets 
in the logical design were mapped in the physical design. In this 
section, signals that are reported as "covered" have been mapped 
completely within a logic cell. 

By default this section is empty, since the section may contain 
thousands of lines and the information is not needed by the 
majority of users. To create this section, select the -detail option 

• Symbol Cross Reference (Section 9)—If enabled, shows where 
symbols in the logical design were mapped in the physical 
design. 

By default this section is empty, since the section may contain 
thousands of lines and the information is not needed by the 
majority of users. To create this section, select the -detail option. 

• lOB Properties (Section 10)—Lists each IOB to which the user has 
supplied constraints along with the applicable constraints. The 
possible IOB properties are shown in the following table; the 
applicability of the properties and options varies from one 


8-28 


Xilinx Development System 




MAP—The Technology Mapper 


architecture to another. The following table applies only to the 
XC4000X. Spartan/XL architectures. 

Table 8-2 IOB Properties 


Property 

Meaning 

Options 

SLEW 

Output slew rate 

SLOW or FAST 


Enable pull-up resistor 

N/A 

PULLDOWN 

Enable pull-down resistor 

N/A 

FF/LATCH 

Input flip-flop/latch data 
source 

NODELAY. 
MEDDELAY, or SYNC 

SYNC 

Fast capture latch data 
source 

NODELAY or 
MEDDELAY 

DRIVE 

Drive value on output 
pads 

12 or 24 ma. 


• RPMs (Section 11 >—Indicates each RPM (Relationally Placed 
Macro) used in the design, and the number of device components 
used to implement the RPM. 


• Guide Report (Section 12>— If you have mapped using a guide 
file, shows the guide mode used (EXACT or LEVERAGE) and the 
percentage of objects that were successfully guided. (This section 
does not apply to Virtex and Spartan2.) 

A sample MAP Report (MRP) file is shown below. 

Note: The MAP Report is formatted for viewing in a monospace 
(non-proportional) font. If the text editor you use for viewing the 
report uses a proportional font, the columns in the report do not line 
up correctly. 


Xilinx Mapping Report File for Design 'tcstcllc' 

Copyright (c) 1995-1999 Xilinx, Inc. All rights reserved. 

Design Information 

Comnand Line : map testclk.ngd 
Target Device : xvlOO 
Target Package : bg256 
Target Speed : -5 

Mapper Version : virtex — Camelian 
Mapped Date : Fn Mar 12 12:09:20 1999 
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Design Surrmary 


Number of errors: 0 

Number of warnings: 5 


Number of Slices: 


64 

out 

of 

1,200 

51 

Slice Flip Flops: 

60 






4 input LUIs: 

98 






Number of bonded ICBs: 


4 

out 

of 

180 

21 

Number of GCLKs: 


2 

out 

of 

4 

501 

Number of GCLKIOBs: 


2 

out 

of 

4 

501 


Total equivalent gate count for design: 1,470 
Additional JTAG gate count for lOBs: 288 


Table of Contents 


Section 

1 - 

Errors 

Section 

2 - 

Warnings 

Section 

3 - 

Design Attributes 

Section 

4 - 

Removed Logic Summary 

Section 

5 - 

Removed Logic 

Section 

6 - 

Added Logic 

Section 

7 - 

Expanded Logic 

Section 

8 - 

Signal Cross-Rcfercnc 

Section 

9 - 

Syrrbol Cross-Rcfercnc 

Section 

10 

- IOB Properties 

Section 

11 ■ 

- RPMs 

Section 

12 ■ 

- Guide Report 

Section 

1 - 

Errors 

Section 

2 - 

Warnings 


WARNING:xvknm - IBUT symbol *C_ckl_i" loutput signal=N_ckl_i ) is promoted 
to indicate the use of GCLKIOB site. 

WARNING:xvkam - 1BUF symbol "C_ck2_i" loutput signal=N_ck2_i» is promoted 
to indicate the use of GCLKIOB site. 

WARNING:basmaprrgr - Ail of the external outputs in this design are using 
slew rate limited output drivers. The delay on speed critical outputs can 
be dramatically reduced by designating them as fast outputs in the 
schema tic. 
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WARNING :baspu - trimming timing constraints from powcr/ground net 
ccre_inst1/countcrl/N5 

WARNING : baspu - trimming timing constraints from powcr/ground net 
corc_inst 1 /countcrl/N 2 fi 

Section 3 - Design Attributes 

Section 4 - Removed Logic Sumnary 
2 block<s) optimized away 

Section 5 - Removed Logic 

Optimized Elock<s>: 

TYPE BLOCK 
VCC C392 
GND C393 

To enable printing cf redundant blocks renoved and signals merged, set the 
detailed map report option and rerun map. 

Section 6 - Added Logic 

Section 7 - Expanded Logic 

To enable this soction ( set the detailed map report option and rerun map. 
Section & - Signal Cross-Reference 

To enable this section, set the detailed map report option and rerun map. 
Section 9 - Symbol Cross-Reference 

To enable this section, set the detailed map report option and rerun map. 

Section 10 - IOB Properties 

ckl_i IGCLXIOB) 
ck2_i IGCLXIOB) 
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out 1 __o (IOB) : $UMb$LON DRIVE-12 
out2_o <IOB) : SLEW=SLOW DRIVE=12 


Section 11 - RPMs 


Section 12 - Guide Rcpcrt 

Guide not supported in this architecture. 

Halting MAP 

To hall MAP. enter CONTROL-C (on a workstation) or CONTROL- 
BREAK (on a PC). On a workstation, make sure that when you enter 
CONTROL-C the active window Ls the window from which you 
invoked the mapper. Tlie operation in progress Ls halted. Some files 
may be left when the mapper is halted (for example, a MAP report 
file or a physical constraints file), but these files may be discarded 
since they represent an incomplete operation. 
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LCA2NCD 


LCA2NCD is compatible wilh the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4Q00E 

• XC5200 

This chapter describes LCA2NCD. The chapter contains the 
following sections. 


• "LCA2NCD Syntax" 

• "LCA2NCD Files" 

• "LCA2NCD Options” 

• "Translating Unnamed Components" 

LCA2NCD 

Earlier releases of the Xilinx Development System stored the physical 
design in a Logic Cell'” Array (LCA™) file. The current Xilinx 
Development System tools operate on physical designs in the NCD 
(Circuit Description) format. LCA files are ASCII (human-readable) 
files; NCD files are binary (machine-readable) files. 

LCA2NCD converts an LCA file to an NCD file. The NCD file 
produced by LCA2NCD can be placed and routed, viewed in the 
FPGA Editor, analyzed for timing, and back-annotated in the current 
Xilinx Development System. 
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Figure 9-1 File Conversion Using LCA2NCD 

LCA2NCD Syntax 

Tine following syntax converts an LCA file to an NCD file. 

Ica 2 ncd [options] lea file]. lca| \ncdjile \\. ncd|| 

Options can be any number of the options listed in the "LCA2NCD 
Options" section. They do not need to be listed in any particular 
order. Separate multiple options with spaces. 

lea.file is the LCA file to be converted. If you enter a file name with no 
extension. LCA2NCD looks for a file with an .lea extension and the 
name you specified. 

ncd file is an optional name for the output NCD file. The output file 
name, its extension, and its location are determined in this way. 

• If you do not specify an output file name, the output file has the 
same name as the input file, with an .ncd extension. 

• If you specify an output file name with no extension, LCA2NCD 
appends the .ncd extension to the file name. 

• If you specify a file name with an extension other than .ncd, you 
get an error message and LCA2NCD does not run. 
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• If you do not specify a full pathname, the output file is placed in 
the directory from which you ran LCA2NCD. 

LCA2NCD Files 

The input files that LCA2NCD requires and the output files that 
LCA2NCD generates are described below. 

Input Files 

Input to LCA2NCD consists of a Xilinx LCA file. This is a mapped 
design file generated in a previous revision of the Xilinx 
Development System. The file may also contain placement and 
routing information. 

Output Files 

Output from LCA2NCD consists of the following files. 

• \'CD file—a physical description of the design in terms of Xilinx 
components (logic cells, I/O cells, etc.). 

• MDF file—MAP Directive File, a file describing how logic was 
decomposed when the design was originally mapped. The MDF 
file is used for guided mapping with the current Xilinx 
Development System software. In guided mapping, the file 
enables MAP to recreate the decompositions chosen when the 
design was first mapped. Tills file is only created if there are 
Mapper directives in the LCA file. 

• L2\' file—a report file containing information about the 
LCA2NCD run. 

LCA2NCD Options 

Following is a description of the command line options and how they 
affect the behavior of LCA2NCD. 

-p (Placement Only) 

If you specif)' the -p option. LCA2NCD includes placement 
information from the input LCA file in the output NCD file, but 
no routing information. 
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-f (Execute Commands File) 

-f command Jilt 

Tlie -f option executes the command line arguments in the specified 
commandJile. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-w (Overwrite Existing File) 

Tine -w option overwrites the output \'CD file if it already exists. By 
default (no -w specified) LCA2NCD does not overwrite an existing 
file. 

Translating Unnamed Components 

A Xilinx LCA file can contain unnamed components. Components 
that are unnamed in an LCA file are dynamically named when used 
in the Xilinx Development System tools; that is, component names 
change depending on whether the components are placed or 
unplaced. 

In an LCA file, components are assigned names using the NmBIk 
construct. Although a component in an LCA file does not have to be 
assigned a name, both the FPCA Editor and PAR require something 
by which to refer to the component. In the Xilinx Development 
System tools, the name applied to a component is dynamic—the 
same component has a different name when it is placed or unplaced. 

If an unnamed component is placed, it is referred to in this way. 

'isileinvncjii 

sitename is the site in which the component is placed 
id is an integer. 

If an unnamed component is unplaced, it is referred to in this way. 
$typename_id 

typeimme Ls the type of component (C1.B, lOB, TBUF, etc.). 
id is an integer. 

If an unplaced component is placed in PAR or the FPGA Editor, or if 
a placed component is unplaced, the string by which it is referred to 
changes. 


9-4 


Xilinx Development System 




LCA2NCD 


Tine FPGA Editor allows you to rename components. If you use the 
FPGA Editor to assign a name to an unnamed component, the name 
you supply then remains with the component, whether the 
component is placed or unplaced. 
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Chapter 10 


The Physical Constraints (PCF) File 


This chapter describes the Physical Constraints File (PCF). The 
chapter contains the following sections. 


• "Interaction Between Constraints" 


The PCF File 

The NGD file produced when a design netlist is read into the Xilinx 
Development System may contain a number of logical constraints. 
These constraints originate in any of these sources. 

• An attribute assigned within a schematic or HDL file. 

• A constraint entered in a UCF (User Constraints File). 

• A constraint appearing in an \'CF (Netlist Constraints File) 
produced by a CAE vendor toolset. 

Logical constraints in the NGD file are read by MAP. MAP uses some 
of the constraints to map the design, and converts other logical 
constraints to physical constraints. MAP then writes these physical 
constraints into a Physical Constraints File (PCF). 

The PCF file is an ASCII file containing two separate sections: a 
section for those physical constraints created by the mapper and a 
section for physical constraints entered by the user. The mapper 
section Ls rewritten every time you run the mapper. Mapper- 
generated physical constraints appear first in the file, followed by 
user physical constraints. This order dictates that in the event of 
conflicts between mapper-generated and user constraints, user 
constraints are last-read and override. The mapper-generated section 
of the file is preceded by a SCHEMATIC START notation on a 
separate line. 


10-1 


Development System Reference Guide—2. Jt 




Development System Reference Guide 


The end of this section is indicated by SCHEMATIC END. also on a 
separate line. User-generated constraints, such as timing constraints, 
should always be entered after SCHEMATIC END. 

You can write user constraints directly into the file or you can write 
them indirectly (or undo them) from within the FPGA Editor. (For 
more information on constraints in the FPGA Editor, see the "Using 
the FPGA Editor" chapter in the FPGA Editor Guide). 

Tine PCF file is an optional input to PAR. the FPGA Editor. TRACE. 
NGDAnno. and BitGen (see the following figure). 

Tine file may contain any number of constraints and any number of 
comments in any order. A comment consists of either a pound sign 
(#) or double slashes (//) followed by any number of other characters 
up to a new line. Illegal constraints are automatically commented out 
by the program. 



X7424 

Figure 10-1 PCF File Flow 
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Interaction Between Constraints 

Schematic constraints are placed at the beginning of the PCF file by 
MAP. The start and end of this section is indicated with 
SCHEMATIC START and SCHEMATIC END. respectively. 
Because of a "last-read" order, all constraints that you enter in this 
file should come after SCHEMATIC END. 

Note: You are not prohibited from entering a user constraint before 
the schematic constraints section, but if you do, a conflicting 
constraint in the schematic-based section may override your entry. 

Every time a design is remapped, the schematic section of the PCF 
file is overwritten by the mapper. The user constraints section is left 
intact, but certain constraints may be invalid because of the new 
mapping. 
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DRC—Physical Design Rule Check 

This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Virtex 

• Spartan/XL/2 

The chapter contains the following sections. 

• "DRC" 

• 'DRC Syntax” 

• -DRC Files" 

• 'DRC Options" 

• -DRC Types" 

• "DRC Errors and Warnings" 
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DRC 

The physical Design Rule Check (DRC) consists ol a series of tests to 
discover physical errors and some logic errors in the design. Three 
Xilinx Development System modules employ physical DRC. The 
physical DRC is used in the following ways. 

• MAP automatically runs physical DRC after it has mapped the 
design. 

• PAR (Place and Route) automatically runs physical DRC on nets 
when it routes the design. 

• You can run physical DRC from within the FPGA Editor. The 
DRC also runs automatically after certain FPGA Editor opera¬ 
tions (for example, when you edit a logic cell or when you manu¬ 
ally mute a net). For a description of how the DRC works within 
the FPGA Editor, see the "Physical Design Rule Check (DRC)" 
section of the FPGA Editor Guide. 

• BitGen. which creates a a BIT file for programming the device, 
automatically runs physical DRC. 

• You can run physical DRC from the UNIX or DOS command line. 

DRC Syntax 

To run DRC, enter the following on the UNIX or DOS command line, 
drc |i>/>fw/ts) file name 

Options can be any number of the DRC options listed in the "DRC 
Options" section. They do not need to be listed in any particular 
order. Separate multiple options with spaces. 

Filejume is the name of the NCD file on which DRC is to be run. 
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DRC Files 

Tills section describes the DRC input and output files. 

Input File 

The input to DRC is an NCD lile. The NCD tile Ls a mapped, physical 
description of your design. 

Output File 

The output of DRC is a TDR file. The TDR file is an ASCII DRC 
report. The contents of this file are determined by the options you 
select for the DRC command. 

DRC Options 

Tills section describes the options that are available for the DRC 
command line. 

-e (Error Report) 

The -e option produces a report containing details about errors only. 
No details are given about warnings. 

-o (Output file) 

-o oulfihjxame 

Tine -o option overrides the default output report file file juimt.idx 
with oulfilejiame Xdr. 

-s (Summary Report) 

The -s option produces a summary report only. The report indicates 
the number of errors and warnings found but does not supply any 
details about them. 

-v (Verbose Report) 

The -v option reports all warnings and errors. This is the default 
option for DRC. 
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-z (Report Incomplete Programming) 

The -z option reports incomplete programming as errors. Certain 
DRC violations are considered errors when the DRC runs as part of 
the BilGen command but are considered warnings at all other times 
the DRC runs. These violations usually indicate the design is 
incompletely programmed (for example, a logic cell has been only 
partially programmed or a signal has no driver). The violations 
would create errors if you tried to program the device, so they are 
reported as errors when BitGen creates a BIT file for device 
programming. If you run DRC from the command line without the -z 
option, these violations are reported as warnings only. With the -z 
option, these violations are reported as errors. 

DRC Types 

Physical DRC can perform four types of checks. 

• Net check—examines one or more routed or unrouted signals 
and reports any problems with pin counts, tristate buffer 
inconsistencies, floating segments, antennae, and partial routes. 

• Block check—examines one or more placed or unplaced 
components and reports any problems with logic, physical pin 
connections, or programming. 

• Chip check—examines a special class of checks for signals, 
components, or both at the chip level, such as placement rules 
with respect to one side of the device, etc. 

• All checks—performs net, block, and chip checks. 

When you run DRC from the command line (as described in the 
previous sections), it automatically performs net. block, and chip 
checks. 

In the FPGA Editor, you can run the net check on selected objects or 
on all of the signals in the design. Similarly, the block check can be 
performed on selected components or on all of the design's 
components. When you check all components in the design, the block 
check performs extra tests on the design as a whole (for example, 
tristate buffeis sharing long lines and oscillator circuitiy configured 
correctly) in addition to checking the individual components. In the 
FPGA Editor, you can run the net check and block check separately or 
together. 
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For a description of how the DRC works within the FPGA Editor, see 
the "Physical Design Rule Check (DRC)~ section in the FPGA Editor 
Guide. 

DRC Errors and Warnings 

A DRC error indicates a condition in which the routing or component 
logic will not operate correctly (for example, a net without a driver or 
a logic block that is incorrectly programmed). A DRC warning 
indicates a condition when* the routing or logic is incomplete (for 
example, a net is not fully routed or a logic block has been 
programmed to process a signal but them is no signal on the 
appiopriate logic block pin). 

Certain messages may appear as either warnings or errors, 
depending on the application and signal connections. For example, in 
a net check, a pullup not used on a signal connected to a decoder 
generates an error message. A pullup not used on a signal connected 
to a tristate buffer only generates a warning. 

Incomplete programing (for example, a signal without a driver or a 
partially programmed logic cell) is reported as an error when the 
DRC runs as part of the BilGen command, but is reported as a 
warning when the DRC runs as part of any other program. The -z 
option to the DRC command reports incomplete programming as an 
error instead of a warning. For a description of the -z DRC option, 
see the ~-z (Report Incomplete Programming)" section. 
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PAR—Place and Route 

This program Is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

Tine chapter contains the following sections. 

• PAR" 

• "PAR and the Timing Analysis Software" 

• "PAR Syntax" 

• "PAR Files" 

• "PAR Options" 

• "PAR Operation" 

• "Guided PAR" 

• "Output from PAR" 

• "Scoring the Routed Design" 

• "Turns Engine (PAR Multi-Tasking Option)" 

• "Command Line Examples" 

• "Halting PAR" 
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PAR 

After a design has undergone the necessary translation to bring it into 
the NCD (Circuit Description) format, it is ready for placement and 
routing. This phase is done by PAR (Xilinx's Place and Route 
program). PAR takes an NCD file, places and routes the design, and 
outputs an NCD file which is used by the bitstream generator 
(BitGen). Tire output NCD file can also act as a guide file when you 
reiterate placement and routing for a design to which minor changes 
have been made after the previous iteration. 

In the Xilinx Development System. PAR places and routes a design 
using a combination of two methods. 

• Cost-based—This means that placement and routing are 
performed using various cost tables which assign weighted 
values to relevant factors such as constraints, length of 
connection, and available routing resources. Cost-based 
placement and cost-based routing are further described in the 
"PAR Operation" section. 

• Timing-Driven—The Xilinx timing analysis software enables 
PAR to place and route a design based upon your timing 
constraints. Timing-driven PAR is described in the "PAR and the 
Timing Analysis Software" section. 

Row through the PAR module is shown in the following figure. Tire 
figure shows a PAR run that produces a single output design file. 


12-2 


Xilinx Development System 




PAR—Place and Route 



Figure 12-1 PAR Flow 

PAR and the Timing Analysis Software 

Timing-driven PAR is based upon Xilinx's liming analysis software, 
an integrated static timing analysis tool (that is, it does not depend on 
input stimulus to the circuit). This means that placement and routing 
arc executed according to timing constraints that you specify in the 
beginning of the design process. The timing analysis software 
interacts with PAR to ensure that the timing constraints you impose 
on the design arc met. 

To use timing-driven PAR, you can specify your timing constraints in 
any of these ways. 

• You can enter the timing constraints as properties in a schematic 
capture or HDL design entry program. 

• You can write your timing constraints into a User Constraints 
File (UCF). This file is processed by NGDBuild when the logical 
design database is generated. 
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To avoid manually entering timing constraints in a UCF tile, use 
the Xilinx Constraints Editor, a tool that greatly simplifies 
constraint creation. For a detailed description of how to use the 
editor, see the Constraints Editor Guide. 

• You can enter the timing constraints in the Physical Constraints 
File (PCF), a file that is generated by MAP. The PCF file contains 
any timing constraints specified using the two previously 
described methods and any additional constraints you enter 
directly in the file. 

Timing-driven placement and timing-driven routing are 
automatically invoked if PAR finds timing constraints in the physical 
constraints file. The physical constraints file serves as input to the 
timing analysis software. The timing constraints supported by the 
Xilinx Development System are described in the "Using Timing 
Constraints" chapter. 

Note: Depending upon the types of timing constraints specified and 
the values assigned to the constraints, PAR run time may be 
increased. 

When PAR is complete, you can verify that the design’s timing 
characteristics (relative to the physical constraints file) have been met 
by running TRACE (Timing Reporter and Circuit Evaluator). Xilinx's 
timing verification and reporting utility. TRACE, which is described 
in detail in the "TRACE" chapter, issues an ASCII report showing 
any timing warnings and errors and other information relevant to the 
design. There is a terse summary report of timing in the PAR report 
also. 

Note: If you are going to run a design without timing constraints, 
better circuit performance most likely can be obtained by enabling 
the Delay Based Cleanup router pass. Alternatively, consider running 
timing driven PAR by supplying timing constraints with the input 
design. 
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PAR Syntax 

The following syntax places and routes your design. 

pat [options] in/i/rj. ncd] out file pcf. file] .pcf 1 

Options can be any number of the PAR options listed in the "PAR 
Options" section. They do not need to be listed in any particular 
order. Separate multiple options with spaces. 

Infile is the design file you wish to place and/or route. The file must 
have an .ncd extension, but you do not have to specify the .ncd 
extension on the command line. 

Ontfile is the target design file which is written after PAR is finished. 
If the command options you specify yield a single output design file, 
oulfile has an extension of .ncd or .dir. An .ncd extension generates an 
output file in NCD format, the .dir extension directs PAR to create a 
directory in which to place the output file (in NCD format). If the 
command options you specify yield more tlian one output design file 
(that is, you enter the -n option described in the "PAR Options" 
section), outfile must have an extension of .dir. Tire multiple output 
files (in NCD format) are placed in the directory with the .dir 
extension. 

If the file or directory you specify already exists, you get an enor 
message and the operation does not run. You can override this 
protection and automatically overwrite existing files by using the -w 
option (described in the "PAR Options' section). 

Pcfjile is a physical constraints file. Tire file contains the constraints 
you entered during design entry, constraints you added using the 
UCF (User Constraints File), and constraints you added directly in 
the PCF file. If you do not enter the name of a physical constraints file 
on the command line and the current directory contains an existing 
physical constraints file with the infile name and a .pcf extension. 
PAR uses the PCF file. 
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PAR Files 

Tills section describes the PAR input and output files. 

Input Files 

Input to PAR consists of the following files. 

• N'CD file—a mapped design. 

• PCF file—an ASCII file containing constraints based on attributes 
in the schematic or on constraints you have placed in a UCF file. 
A complete list of constraints can be found in the "Attributes, 
Constraints, and Carry Logic" chapter of the Libraries Guide'. PAR 
supports all of the timing constraints described in that chapter. 

• Guide NCD file—an optional template file for placing and 
routing the design. 

Output Files 

Output from PAR consists of the following files. 

• NCD file—a placed and routed design file (may contain 
placement and routing information in varying degrees of 
completion). 

• PAR file—a PAR report including summary information of all 
placement and routing iterations. 

• DLY file—a file containing delay information for each net in the 
design. 

• PAD file—a file containing I/O pin assignments. 

• Guide Report File—a file created if you use the -gf option 

• Intermediate Failing TimespeeSummary— a summary generated 
for failing timing specifications 

• Xilinx Par Information— This XPI report displays whether or not 
the design routed and if liming specifications were met. 
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PAR Options 

You can customize the PAR operation by specifying options when 
you run PAR. You can have PAR place without routing. You can 
have PAR perform a single placement, or perform a number of place¬ 
ments using different cost tables. You can specify an effort level to 
indicate to PAR whether the design is simple or complex. You can 
also specify the maximum number of passes the router may perform 
and the number and type of cleanup passes the router runs. 

PAR options are entered on the command line in any order, preceded 
by a hyphen (-), and separated by spaces. You must enter options in 
lower case letters. For those options that require an additional 
parameter, the option and the parameter must be separated by spaces 
or tabs. Options that do not require an additional parameter may be 
grouped together preceded by a single hyphen (for example, -nvx is 
the same as -r -w -x). 

Following is a description of the command line options and how they 
affect the behavior of PAR. If you run PAR with illegal options or do 
not specify an input file, a brief listing of the supported options and 
their functions is printed on the screen. If you want to view all of the 
options, type the following on the command line. 

par | no re 

Tills allows you to scroll through the options. 

OR 

par >filename 

This redirects the options to a file that you specify. 

-c (Number of Cost-Based Router Cleanup Passes) 

-C COSt_pOSSCS 

If you run both cost-based cleanup passes and delay-based cleanup 
passes (see -d and -e options below), the cost-based passes run 
before the delay-based passes. The valid range of cost ^passes is 0-5. 
Tine default setting for -c is I for all devices except Virtex, which is 0. 

Following are some strategies for using the cleanup routers (either 
cost or delay based). 
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• On non-liming driven runs, cleanup routing can significantly 
improve delays and is, in fact, mandatory for XC.VXX) devices. 

• If cost-based cleanup does not yield the desired performance on a 
non-timing driven run, running a delay-based cleanup pass may 
often significantly improve circuit performance. 

• For timing-driven runs, the cleanup passes can improve timing 
on those elements of the design that are not covered by timing 
constraints. 

• Also, for designs in which normal iterative routing is not quite 
making the timing goal (but is somewhat close, say 3 - 5%) a 
delay-based cleanup pass can sometimes reorganize the routing 
enough such that follow-up re-entrant iterative routing passes 
are then able to meet timing. 

Note: The -c option is not recommended for use with Virtex or 
Spartan2. The evaluation of this option with these architectures 
indicates that the option creates much longer runtimes with hardly 
any improvement. 

-d (Number of Delay-Based Router Cleanup Passes) 

-d delay_peisses 

If you do not use the -d option, the router does not run any delay- 
based cleanup passes (described in the "Routing" section). If you run 
both delay-based cleanup passes and cost-based cleanup passes (see 
-c option above), the cost-based passes run before the delay-based 
passes. Typically, the first delay-based cleanup pass produces the 
greatest improvement, with less improvement on each successive 
pass. It is also possible that delay passes do not show any 
improvement. 

Tine valid range of delayjusses is 0-5, and the default is 0. 

If you want to run delay-based cleanup passes only on designs that 
have been routed to completion ( 100 % routed), use the -e option 
(described below) instead of the -d option. 

Note: The -d option is not recommended for use with Virtex or 
Spartan2. The evaluation of this option with these architectures 
indicates that the option creates much longer runtimes with little 
improvement. 
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-dfs (Thorough timing analysis of paths) 

Tine -dfs option specifies that PAR utilize depth-first search timing 
analysis, which analyzes all paths covered by liming constraints in 
order to perform timing-driven place and route. This method is more 
thorough than the default method (-kpatlns) and may result in longer 
PAR runtimes. See the "-kpatlns (Faster Analysis of Paths)" section for 
a discussion of the connection-based method. 

-e (Delay-based cleanup passes—Completely 
Routed Designs) 

-e number 

Tine -e option operates in the same way as the -d option described 
previously, but the -d option runs on all output designs produced by 
the PAR run, while the -e option only runs on those output designs 
which have been routed to completion. Tine number of passes is 0-5, 
and the default is 0 . 

Note: This option is not recommended for use with Virtex or 
Spartan2. The evaluation of this option with these architectures 
indicates that the option creates much longer runtimes with little 
improvement. 

-f (Execute Commands File) 

-f command .file 

The -f option executes the command line arguments in the specified 
command Jile. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-gf (Guide NCD File) 

-gf guideJUe 

Tine -gf option specifies the name of an NCD file (from a previous 
MAP or PAR run) to be used as a guide for this PAR run. Tine guide 
file is an NCD file which is used as a template for placing and routing 
the input design. For more information on the guide file, see the 
"Guided PAR" section. 
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-gm (Guide Mode) 

-gtn (exact I leverage] 

The -gm option specifies the form of guided placement and routing 
PAR uses—exact or leveraged. Tire default is exact mode. For more 
information on the guide modes, see the "Guided PAR" section. 

You specify the NCD to use as a guide file by entering a -gf option 
(see the "-gf (Guide NCD File)" section) on the PAR command line. If 
you do not specify a guide file, PAR is guided by the placement and 
routing information in the input NCD file. The "Guided PAR" section 
describes how PAR operates if no guide file is specified. 

-i (Number of Router Iterations) 

-i roulejtasses 

Run a maximum number of passes of the router, slopping earlier only 
if the routing goes to 100% completion and all constraints am met. 
Each pass is a single attempt to route a placement to completion, and 
the semen displays a message for each pass. 

Tire valid range of route, passes is 0-20CX). If you do not use the -i 
option, the router runs until it either routes to 100% completion and 
meets its liming constraints or intelligently determines it will not 
succeed. 

-k (Re-Entrant Routing) 

Tire -k option runs re-entrant (also called incremental) routing. 
Routing begins with the existing placement and routing left in place. 
Re-entrant routing is useful if you wish to manually mute parts of the 
design and then continue automatic routing, if you halted the mute 
prematurely (for example, with a Contml-C) and wish to resume, or 
if you wish to run additional route or delay reduction passe.. 

-kpaths (Faster Analysis of Paths) 

Tire non-enumerative connection-based method (the default method) 
has a runtime proportional to the size of the design, unlike the DFS 
method, which has a runtime pmportional to the number of paths in 
the design. 
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There are two significant differences between the connection-based 
method and the DF5 method. 

• The DFS method analyzes all paths except those that actually 
contain a circuit cycle, including paths that contain connections 
that cause a circuit cycle for other paths in the circuit. The 
connection-based method may not analyze thase paths 
depending on circuit topology. Consider the following example 
circuit 



Figure 12-2 Circuit Cycles 

The DFS method traces the path from IN. through A. through the 
signal LOOP, back to the left-most logic block and to the signal 
OLT. The new connection-based method may not trace this path 
because a combinatorial cycleexLsis at the output of A. 

• The DFS method ivmovas faLse paths from a design that requiras 
contending tristate enable signals. The connection-based method 
doas not perform this optimization which means that it may 
analyze some paths that an? statically false based on tristale 
enable signals. Consider the following circuit. 
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Figure 12-3 Tristate Buffer Paths 

A signal can pass through four paths in the preceding circuit but two 
of the paths are false |A1 to B2 and B1 to A2). In order for a signal to 
pass though the upper left tristale buffer Al, the enable signal A 
must be true. In order to prevent a bus contention on the A1 output, 
the enable signal B must be false. Since buffer B2 is also controlled by 
the enable signal B, the path through Al cannot pass through B2 
(because when A is enabled, B is disabled). The converse is also true, 
if B is enabled, the only valid path Is from B1 to B2. 

In the example circuit, the DF5 method only considers true paths. The 
connection-based will trace the false paths and the true paths. 

-I (Overall Effort Level) 

-1 effort Jevtl 

The -1 option is identical to the -o! option. See the "-ol (Overall Etfort 
Level)" section. 

-m (Multi-Tasking Mode) 

-ra nodefilejuvne 

The -m option allows you to assign PAR multi-run jobs (specified 
with the -n option) to a group of nodes. See the "Turns Engine <PAR 
Multi-Tasking Option)" section. 
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-n (Number of PAR Iterations) 

-n iterations 

The -ii option determines the number of iterations (place and route 
passes) performed at the effort level specified by the -1 option. 

Each iteration uses a different cost table when the design is placed 
and produces a different NCD file. If you enter -n 0. the software 
continues to place and route, stopping either after the design is fully 
routed or after completing the iteration at cost table 100 and meeting 
all timing constraints. If you don't specify the -n option, one place 
and route iteration runs. 

If you specify a -t option, the iterations begin at the cost table 
specified by -t. 

Tire valid range of iterations is 0-100, and the default is 1. 

-ol (Overall Effort Level) 

-ol effortJevel 

Tire -ol option sets the overall PAR effort level. The effort level 
specifies the level of effort PAR uses to place and route your design to 
completion and achieve your tinring constraints. 

There are five values for effort level. Level 1 is the lowest level, and 
corresponds to the least complex design. Level 5 would be used on 
the most complex design. The level is not an absolute; it shows 
instead relative effort. After you use PAR for a while, you will be 
better able to estimate whether a design is simple or complex. 

If you place and route a simple design at a complex level, the design 
is placed and routed properly, but the process takes more time than 
placing and routing at a simpler level. If you pLrce and route a 
complex design at a simple level, the design may not route to 
completion or may mute less completely (or with worse delay 
characteristics) than at a more complex level. 

The effort level range is 1-5, and the default level is 2. 
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The -ol level sets an effort level for placement and another effort level 
for routing. These levels also have a range of 1-5. The placement and 
muting levels set at a given -ol level depend on the device family in 
the NCD file. You can determine the default placer and router effort 
levels for a device family by reading the PAR Report file produced by 
your PAR run. 

You can override the placer level set by the -ol option by entering a 
-pi (Placer Effort Level) option, and you can override the router level 
by entering a -rl (Router Effort Level) option. 

-p (No placement) 

The -p option bypasses both constructive and optimizing placement 
(described in the "Placement" section). When you use this option, 
existing routes are ripped up before routing begins. You can. 
however, leave the existing routing in place if you use the -k option 
instead of the -p option. 

-pl (Placer Effort Level) 

-pi placer_efforl_level 

Tlie -pl option sets the placer effort level. Tlie effort level specifies the 
level of effort used when placing the design. Level 1 is the lowest 
level, and corresponds to the least complex design. Level 5 would be 
used on the most complex design. For a description of effort level, see 
the "-ol (Overall Effort Level)" section. 

The placer effort level range is 1-5. and the default level set if you do 
not enter a -pl option is determined by the setting of the -ol option. 
This default varies depending on the device family in the input NCD 
file. You can determine the default placer effort level for a given -ol 
level and device family by reading the PAR Report file produced by 
your PAR run. 

-r (No Routing) 

Do not route the design. 


12-14 


Xilinx Development System 




PAR—Place and Route 


-rl (Router Effort Level) 

-rl totiler_effortJii'i'l 

The -rl option sets the router effort level. The effort level specifies the 
level of effort used when routing the design. Level 1 is the lowest 
level and corresponds to the least complex design. Level 5 would be 
used on the most complex design. For a description of effort level, see 
the "-ol (Overall Effort Level)" section. 

Tine ’ouler_effort Jtvei range is 1-5, and the default level set if you do 
not enter a -rl option Ls determined by the setting of the -ol option. 
This default varies depending on the device family in the input NCD 
file. You can determine the default router effort level for a given -ol 
level and device family by reading the PAR Report file produced by 
your PAR run. 

-s (Number of Results to Save) 

-a numberJo_pave 

Tire -s option saves only the number of results you specify. If you do 
not use the -s option, all results are saved. 

Tire -s option does not care how many iterations you performed or 
how many effort levels were used. It compares every result to every 
other result and leaves you with the best number of NCD files. The 
best outputs are determined by a score assigned to each output 
design. This score takes into account such factors as the number of 
unrouted nets, the delays on nets and conformance to your timing 
constraints. The lower the score, the better the design. This score is 
described in the "Scoring the Routed Design" section. 

Tire valid range for number to_stnv is 0-100, and the default -s setting 
(no -s option specified) saves all results. 
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-t (Starting Placer Cost Table) 

-t placerj&stjable 

Tile -1 option specifies the cost table at which the placer starts (placer 
cost tables aie described in the Placement" section). If you do not 
specify the -t option, the PAR software starts at placer cost table 1. If 
cost table 100 is reached, placement does not begin at 1 again, even if 
command options specify that more placements should be 
performed. Cost tables are not an ordered set. There is no correlation 
between a cost table's number and its relative value. 

The placer _cost_lable range Ls 1-100, and the default is 1. 

-ub (Use Bonded I/Os) 

If you do not specify the -ub option, I/O logic that MAP has 
identified as internal can only be placed in unbonded I/O sites. 

If the -ub option is specified. PAR can place this internal I/O logic 
into bonded I/O sites in which the I/O pad is not used. The option 
also allows PAR to route through bonded I/O sites. 

If you use the -ub option, you must make sure this logic Ls not placed 
in bonded sites connected to external signals, power, or ground. You 
can prevent this condition by placing PROHIBIT constraints on the 
appropriate bonded I/O sites. 

-w (Overwrite Existing Files) 

If the specified output file already exists, overwrite the existing file 
(including the input file). 

If the specified output Ls a directory, overwrite files in the directory. 
With this option, any PAR, PAD, and DLY files generated overwrite 
existing PAR, PAD. and DLY files. 

-x (Ignore Timing Constraints) 

If you do not specify the -x option, the PAR software automatically 
runs a timing-driven PAR run if any timing constraints are found in 
the physical constraints file. If you do specify -x, timing-driven PAR 
is not invoked in any case. 
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Tine -x option might be used if you have timing constraints specified 
in your physical constraints file, but you want to execute a quick PAR 
run without using the timing-driven PAR feature, to give you a 
rough idea of how difficult the design is to place and route. 

Summary of PAR Options 


Options, default values, and ranges are summarized below. 


Option 

Default Setting 

Range 

-c number 

Tine default setting for -c is 1 for all 
devices except Vi ilex, which is 0. 

0-5 

-d number 

0 (No delay-based router cleanup 
passes) 

0-5 

-dfs 

Run connection- based method 
(No -dfs, -kpaths is the default) 

N/A 

-e number 

0 (No delay-based router cleanup 
passes on completely routed designs) 

0-5 

-gC 

No guide file 

N/A 

-gm (leverage 1 exact) 

Exact 

N/A 

-i number 

Run until completion or until router 
decides it can not complete 

0-2000 

-k 

Run placement (Do not run re-entrant 
routing) 

N/A 

-kpaths 

Run connection-based method 
(-kpaths is the default) 

N/A 

-1 number 

2 (Overall effort level 2) 

1-5 

-m nodefitejtame 

Do not run the Turns Engine 

N/A 

-n number 

1 (One place and route iteration) 

0-100 

-ol number 

2 (Overall effort level 2) 

1-5 

-P 

Run placement 

N/A 

-pi number 

Determined by -ol setting 

1-5 

-r 

Run router 

N/A 

-rl number 

Determined by -ol setting 

1-5 

-a number 

Save all 

1-100 
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Option 

Default Setting 

Range 

-t number 

1 (Start placer at cost table 1) 

1-100 

-lib 

Do not use bonded I/Os 

N/A 

-w 

Do not overwrite 

N/A 

-x 

Use timing constraints in PCF file 

N/A 


PAR Operation 

Tine following sections describe how placement and routing are 
performed by PAR. 


Placement 

The PAR module places in two stages: a constructive placement and 
an optimizing placement. PAR writes the NCD file after constructive 
placement and modifies the NCD after optimizing placement. 

During constructive placement, PAR places components into sites 
based on factors such as constraints specified in the input file (for 
example, certain components must be in certain locations), the length 
of connections, and the available routing resources. This placement 
also takes into account "cost tables", which assign weighted values to 
each of the relevant factors. There are 100 possible cost tables. 
Constructive placement continues until all components are placed. 
PAR writes the NCD file after constructive placement. 

Tire optimizing placement is a fine tuning of the results of the 
constructive placement. Optimizing is run only at specific levels, and 
the number of passes may vary. PAR rewrites the NCD file after 
optimizing placement. 

Timing-driven placement is automatically invoked if PAR finds 
timing constraints in the physical constraints file. 

Routing 

Routing is done in two stages: constructive routing and cleanup. PAR 
writes the NCD file only at the end of an iteration after more than <i0 
minutes of routing have elapsed, and it only writes out a new NCD 
file if the design quality improves. 
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During constructive routing, the router performs an iterative 
procedure to converge on a solution that accomplishes these goals. 

• Routing the design to completion. 

• Meeting your timing constraints. 

If both of these goals cannot be met, the first is considered more 
important, that is, PAR tries to route to completion even if your 
timing constraints are not met. 

During cleanup routing, the router takes the result of constructive 
■outing and reroutes some connections to accomplish these goals. 

• Minimizing the delays on all nets. 

• Decreasing the number of routing resources used. 

If both of these goals cannot be met, the first is considered more 
important; that is, PAR tries to route to minimize delays in preference 
to decreasing the number of routing resources used. 

Tile re are two types of cleanup routing you can perform—a faster 
cost-based cleanup routing and a more intensive delay-based cleanup 
routing. Cost-based cleanup runs much faster than delay-based 
cleanup, but delay-base cleanup usually produces a result that has 
faster in-circuit performance. 

Timing-driven routing is automatically invoked if PAR finds timing 
constraints in the physical constraints file. 

Note: To achieve your timing constraints while routing an XC4000E/ 
L/EX/XL design, PAR may add an additional pullup to a net at the 
output of a TBUF. PAR adds this pullup to the longline on which the 
net is routed. The pullup is added if the net contains a single pullup 
and the design has been completely routed, but the net containing the 
pullup has one or more timing errors. 
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Guided PAR 

You can use guide files to modify your design incrementally or you 
can integrate your design with PCI Core guide files. The following 
sections describe both types of guided PAR use. 

Incremental Designs 

An optional guide design file can be fed into PAR. The guide file is an 
N'CD file which is used as a template for placing and routing the 
input design. Tills is useful if minor incremental changes have been 
made to create a new design. To increase productivity, you can use 
your last design iteration as a guide design for the next design 
iteration, that is. your output NCD file becomes the guide design file 
for your next iteration of the design (see the following figure). 


First PAR Run 


Second PAR Run 



Figure 12-4 Guided PAR for Incremental Design 

Two command line options control guided PAR. The -gf option 
specifies the N’CD guide file, and the -gm option determines whether 
exact mode or leveraged mode is used to guide PAR. 

Tine guide design is used as follows. 
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• If a component in the new design is constrained to the same 
location that a component is placed in the guide file, this 
component will be defined as matching. 

• If a component in the new design has the same name as a 
component in the guide design, that component will match the 
guide component. 

• If a signal in the new design lias the same name as a signal in the 
guide design, the signal will match the guide signal. 

• Any matching component in the new design will be placed in the 
site corresponding to the location of the matching guide compo¬ 
nent. if possible. 

• Matching component's pins will be swapped to match those of 
the guide component with regard to matching signals, if possible. 

• All of the connections between matching driver and load pins of 
the matching signals will have the routing information preserved 
from the guide file, if possible. 

When PAR runs using a guide design as input, PAR first places and 
mutes any components and signals that fulfill the matching criteria 
described above. Then PAR places and routes the remainder of the 
logic. 

To place and mute the remainder of the logic, PAR does the 
following. 

• If you have selected exact guided PAR (by entering the -gm 
exact option on the PAR command line), the placement and 
muting of the matching logic are locked. Neither placement nor 
muting can be changed to accommodate the additional logic. 

• If you have selected leveraged guided PAR (by entering the -gm 
leverage option on the PAR command line), PAR tries to 
maintain the placement and muting of the matching logic, but 
changes placement or routing if it is necessary in order to place 
and route to completion and achieve your timing constraints (if 
possible). 

Some cases where the leveraged mode is necessary are as follows: 

• You have added logic that makes it impossible to meet your 
timing constraints without changing the placement and 
muting in the guide design. 
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• You have added logic that demands a certain site or certain 
routing resource, and that site or routing resource is already 
being used in the guide design. 

As one example of this condition, in XC4(XX)EX devices 
TBUFs must be routed along long lines. If you add TBUFs to 
an XC4000EX design but your guide design uses too many of 
the required long lines, you are not able to route this design 
to completion unless you use the leveraged option. 

If you enter a -gm (guide mode) option but do not specify a guide file 
with the -gf option, PAR is guided by the placement and routing 
information in the input NCD file. Depending on whether you 
specify exact mode or leveraged mode, PAR locks the input NCD's 
existing placement and routing (exact mode), or tries to maintain the 
placement and routing, but modifies them in an effort to place and 
route to completion and achieve your timing constraints (leveraged 
mode). 

Note: For Verilog or VHDL netlist input designs, re-svnthesizing 
modules typically cause signal and instance names in the resulting 
netlist to be significantly different from the netlist obtained in earlier 
synthesis runs. This occurs even if the source level Verilog or VHDL 
code only contains a small change. Because guided PAR depends on 
signal and component names, synthesis designs often have a low 
"match rate" when guided. Therefore, guided PAR is not recom¬ 
mended for most synthesis-based designs, although there may be 
cases where it could be a successful alternative technique. 

PCI Cores 

For the 2.1i release, you can use a guide file to add a PCI Core, which 
is a standard I/O interface, to your design. The PCI Core guide file 
must already be placed and routed. PAR only places and routes the 
signals that run from the PCI Core to the input N'CD design; it does 
not place or route any portion of the PCI Core. You can also use the 
resulting design (PCI Core integrated with your initial design) as a 
guide file. However, you must then use the exact option for -gm, not 
leverage, when generating a modified design. 

Guided PAR supports more precise matching of placement and 
routing of PCI Cores that are used as reference designs in a guide file; 
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• Components locked in the input design are guided by 
components in the reference design of a guide file in the 
corresponding location. 

• Signals that differ only by additional loads in the input design 
will have the corresponding pins routed according to the 
reference design in the guide file. 

• Guide summary information in the PAR report describes the 
amount of logic from the reference design that matches logic in 
the input design. 

For detailed information about designing with PCI, refer to the Xilinx 
PCI web page (http://www.xilinx.com/prvxlucts/logicore/pci/ 
pcilit.htm). 

Output from PAR 

Tire output of PAR is a placed and routed NCD file (the output 
design file). In addition to the output design file, a PAR run generates 
a report file with a .par extension, a delay file with a .dly extension, 
and a pinout file with a .pad extension. Tire PAR file contains execu¬ 
tion information about the place and route job as well as all constraint 
messages. The DLY file contains delay information about the routed 
nets in the design. The PAD file lists IOBs (Input/Output Blocks) on 
the chip and the primary pins associated with the IOBs. 

If the options that you specify when running PAR are options that 
pioduce a single output design file, your output is the output design 
file, a PAR file, a DLY file, and a PAD file. The PAR file, the DLY file, 
and the PAD file all have the same root name as the output design 
file. 

If you run multiple iterations of placement and muting, you pioduce 
an output design file, a PAR file, a DLY file, and a PAD file for each 
iteration. Consequently, when you run multiple iterations you have 
to specify a directory in which to place tliese files. 

As the command is performed, PAR records a summary of all 
placement and routing iterations in one PAR file at the same level as 
the directory you specified, then places the output files (in NCD 
format) in the specified directory. Also, a PAR file, a DLY file, and a 
PAD file are created for each NCD file, describing in detail each 
individual iteration. 
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For example, suppose you have a directory named design with a 
design file called address.ncd, as shown in the following figure. 


4d*»»vr>:d 


X7231 

Suppose you run three iterations of place and route, using a different 
cost table entry each time (cost tables are explained in the 
"Placement" section) and specify that the resulting output be put into 
a directory called output.dir. The actual command would be 

pat -n 3 -1 1 address.ncd output.dir 

-n 3 is the number of iterations you want to run, -1 1 sets the 
placement effort level, address. ncd is your input design file, and 
output. dir is the name of the directory in which you want to place 
the results of the PAR run. 

Tine files resulting from the command are shown in the following 
figure. 



I_1 I .UJ I I.1.2JK4 1.1 1.1 1M« 1-1.1^ 


xnu 


The miming convention for the files, w hich may contain placement 
and routing information in varying degrees of completion, Ls 
placerJevd router Jcvel_ tMe.f/le extension. 
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In Ihe sample above, Ihe effort level and cost (able entries star! at 1 
(the default value). The PAR. DLY, and PAD liles are described in the 
following sections. When you run multiple iterations, you get a 
summary PAR report file like the one shown below. 

Note: The PAR Report is formatted for viewing in a monospace (non¬ 
proportional) font. If the text editor you use for viewing the report 
uses a proportional font, the columns in the report do not line up 
correctly. 

PAR: Xilinx Place And Route 2.11. 

Copyright (c) 1995-1999 Xliinx, Inc. All rights reserved. 


Mon Mar 15 09:20:<16 1999 


par -ol 2 -n 5 -i 20 aain_pcb.ncd nain_pcb.pcf 


Constraints file: main_pcb.pcf. 


Level/ 

Design 

7ining 

Cost [ned) 

Score 

Score 

3_3_1 * 

716 

0 

3-3-5 • 

724 

0 

3_3_2 • 

730 

0 

3_3_4 * 

612 

0 

3—3_3 • 

627 

0 


* : Design saved, 
par done! 


Humber 

Run 

NCD 

Unrouted 

Tire 

Status 

0 

01:02 

Correlate 

0 

01:06 

Corrplctc 

0 

01:05 

Coupletc 

0 

01:06 

Corrplctc 

0 

01:13 

Complete 


At the top of the summary PAR file is information regarding the 
software level, copyright information, and the date and time of the 
run. Directly below that is the command line used to run PAR. 
followed by the name of any physical constraints file used. 

Tire body of the report consists of the following columns. 

level /Cost [ ned 1 —indicates the effort level (1-5) at which PAR is 
run. In the sample above, 3_3 4 indicates placer level 3, router level 3, 
and the fourth cost table used. 
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Desiyn Score—see "The Place and Route (PAR) Report File" 
section. 

Timiny Score—see "The Place and Route (PAR) Report File" 
section. 

Number Unrooted—indicates the number of unrouted nets in the 
design. 

Run Time—the time required to complete the Job in minutes and 
seconds. 

NCD Status—describes the state of the output NCD file generated 
by the PAR run. Possible values for this column are 

• Complete—an NCD file lias been generated by a full PAR run. 

• 'C Checkpoi nt—initiated by the user, the PAR run was 
stopped at one of the PAR checkpoints. PAR produced an NCD 
file, but all iterations may not have been completed. 

• Checkpoint—the PAR run was stopped at one of the PAR 
checkpoints, not because of user intervention but because of 
some unknown reason. 

• Ho NCD—the PAR job was stopped prematurely and the NCD file 
was not checkpointed. 

Intermediate Failing Timespec Summary 

PAR generates an intermediate failing timespec summary only in the 
muting phase. The summary name is design. muneMr. 

The muter creates this summary after an iteration not during an 
iteration. If interrupted during normal operation of an iteration (for 
example, CTRL-C), you an? prompted with the following options if a 
time specification lias failed. 

CNTRL-C interrupt detected. 

Please chcose one ot the following options: 

1. Continue processing and ignore the interrupt. 

2 . Hornal progran exit at next check point. 

This will result in saving the best results so far, 
•er concluding current processing. 

3. Exit program irrenediately. 
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4. Display Failing Tinespec Sumnary. 

5. Cancel the current 30 b and move to the next one at 
the next check point. 

Enter choice —> 

If you select 3. PAR exits. If you select 4, PAR displays the contents of 
the ITR file on the screen and resumes execution. (Option 5 allows 
you to terminate jobs that use the -n option for multiple iterations.) If 
Options 4 and 5 are not applicable, the following messages displays 
for those options on a CTRL C instead of the ones shown previously. 

4. Display Failing Tiaospcc Sumnary. 

(Not applicable: Data not available) 

5. Cancel the current Job and move to the next one at 
the next chock point. 

INot applicable: Not a nulti-run job.) 

Following is a sample ITR report. 

Asterisk (*) preceding a constraint indicates it was not net. 


Constraint 


I Requested | Actual 
I I 


I Logic 
1 Levels 


* OFFSET = OUT 15 nS AFTER CCMP •ckl_i ,, | 15.000ns | 15.&00ns | 5 


1 constraint not met. 

PAR creates an intermediate failing timespec summary generated 
from the end of the previous iteration. If the interrupt occurred 
during the first iteration, no intermediate summary is created. 

The Place and Route (PAR) Report File 

The place and route (PAR) report file contains execution information 
about the PAR command run. The file shows the steps taken as the 
program converge* on a placement and routing solution. A sample 
PAR file is shown following. 

Note: The PAR Report is formatted for viewing in a monospace (non¬ 
proportional) font. If the text editor you use for viewing the report 
uses a proportional font, the columns in the report do not line up 
correctly. 
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PAR: Xilinx Place And Route 2.1i. 

Copyright <c) 1995-1999 Xilinx, Inc. All rights reserved. 
Fri tor 12 12:09:2ft 1999 


par -w testclk.ncd testclk.ncd 


Constraints file: testclk.pcf. 

Loading device database for application par from file "testclk.ncd". 

•tcst^clock* is an NCD r version 2.20, device xcvlGO, package bg2S6, 
speed -5 

Loading device for application par from file 'vlOO.nph' in environment 
/build/bcxfndry/C.13/rtf. 

Device speed data version: "xl__0.71 1.76 Advanced*. 


Device utilization sunmary: 


Number 

of 

External GCLXIOBs 

2 

out 

of 

4 

50% 

Number 

of 

External lOBs 

4 

out 

of 

lftO 

2 % 

Number 

of 

SLICES 

64 

out 

of 

1200 

5% 

Number 

of 

GCLKs 

2 

out 

of 

4 

50% 


Overall effort level l-ol>: 2 (default) 

Placer effort level <-pl): 2 (default) 

Placer cost table entry l-t): 1 
Router effort level <-rl): 2 (default) 

Timing metnod (-kpatfts|-dfs): kpaths (default) 


Starting initial Timing Analysis. REAL time: 5 secs 
Finished initial Timing Analysis. REAL time: 7 secs 


Starting initial Placement phase. REAL time: 
Control signal source res.i 

shed initial Placement phase. REAL time: 
Starting the placer. REAL time: ft secs 
Placement pass 1 ... 

Placer score = 7420 
Optimizing .. . 

Placer score = 5962 


sees 

secs 
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Starting IO Improverrent. REAL time: 5 secs 
Placer score = 5211 

..led IO Improvement. REAL time: 8 secs 

Placer completed in real time: 8 secs 

Total REAL time to placer completion: 8 secs 
Total CPU time to placer completion: 5 secs 

0 connect ion(s} routed; 380 unrouted. 

Starting router resource preassignnent 

Completed router resource preassignment. REAL time: 10 secs 
Starting iterative routing. 

Routing active signals. 

End of iteration 1 

380 successful; 0 unrouted; <0) REAL tine: 12 secs 
Constraints are net. 

Routing PKR/GND nets. 

Power and ground nets conplctcly routed. 

Total REAL time: 12 secs 
Total CPU time: 0 secs 

End of route. 380 routed (100.00%); 0 unrouted. 

No errors found. 

Completely routed. 

Total REAL time to router completion: 13 secs 
Total CPU time to router completion: 8 secs 

Generating 'par" statistics. 

The Delay Sumnary Report 

The SCORE FOR THIS DESIGN is: 264 


The NUMBER OF SIGNALS NOT COMPLETELY ROUTED for this design is: 0 

The AVERAGE CONNECTION DELAY for this design is: 1.958 

The MAXIMUM PIN DELAY IS: 6.466 

The AVERAGE CONNECTION DELAY on the 10 WORST NETS is: 3.445 

sting Pin Delays by value: (nsec) 

d < 1.00 < d < 2.00 < d < 3.00 < d < 4.00 < d < 7.00 d >= 7.00 
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87 165 70 18 40 0 

Timing score: 0 

Asterisk (*) preceding a constraint indicates it was not net. 


Constraint 


1 

Requested 

1 Actual I 

Lcqic 




1 

1 

Love1s 

T3_ckl_i = PERIOD 

TIMEGRP 

H ckl_i* 20 nS 

1 20 . 000 ns 

1 14.655ns 

1 12 

HIGH 50.000 % 



1 

1 

1 

T5_ck2_i = PERIOD 

TIHEGRP 

H ck2_i* 18 nS 

I 18 . 000 ns 

I 14.813ns 

1 H 

HIGH 50.000 % 



1 

1 

1 

OFFSET = IN 20 nS 

BEFORE 

COMP *ckl_i* 

1 20 . 000 ns 

1 6 . 202 ns 

1 2 

OFFSET = OUT 18 nS 

AFTER 

COMP "ckl_i* 

I 18 . 000 ns 

I 16.691ns 

1 5 

OFFSET = IN 22 nS 

BEFORE 

COMP "ck2_i* 

I 22 . 000 ns 

| 5.861ns 

1 2 

OFFSET = OUT 17 nS 

AFTER 

COMP "ck2_i* 

1 17.000ns 

1 14.969ns 

1 5 


All constraints were net. 

Sometimes the design is completely routed, but the router continues 
to route in the attempt to meet timing constraints. 

Note that in the sample PAR tile above, in the "starting iterative 
routing" section, after the end of iteration 1 , there is a figure in 
parentheses (0). Tills represents the timing score for the design (not to 
be confused with the PAR score) at the end of the particular iteration. 
This figure appears in the PAR file only when timing constraints have 
been specified in a PCF file. When the timing score is 0 (as it is in this 
example after iteration 1 ), this means that all timing constraints have 
been met. This score (0) also appears at the end of the delay report 
section of the PAR file. 

Tine timing score at the end of the "starting iterative routing" section 
may not agree with the timing score in the Delay Summary Report. 
Tills can occur if a MAXSKEW constraint is scored and not met. 

Had the design been completely routed but failed to meet all liming 
constraints, the score would have been a figure other than 0. A non- 
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zero number would appear al Ihe end of Ihe delay report section. 
This tells you immediately whether your timing constraints have 
been met. It is possible that the timing score shown in parentheses at 
the top of the file may be different from the one shown in the delay 
summary section of the file. The score shown in the delay summary 
section is always the correct one. 

The last section of the PAR file contains a summary of the delay 
information for Ihe routed design. The DLY (delay) file produced by 
the PAR run contains more detailed timing information. The DLY file 
is discussed in the following section. 

If you specify a command option that pn>duces multiple output 
design files, there is a PAR file indicating all of the place and route 
iterations performed, and individual PAR files describing placement 
and routing for each design file produced. 

Note: In PAR reporting, a tilde (-) preceding a delay value indicates 
that the delay value is approximate. Values with Ihe tilde cannot be 
calculated exactly because of excessive delays, resistance, or 
capacitance on the net. You can use Ihe PENALIZE TILDE constraint 
to penalize these delays by a specified percentage (see the "TRACE" 
chapter and the "Attributes, Constraints, and Carry Logic" chapter of 
the Libraries Guide for a description of the PENALIZE TILDE 
constraint). 

Some notes about the entries in the PAR file. 

• The Placer score is a rating of the relative "cost" of a placement. A 
lower score indicates a better (that is, less "costly") placement. 

• In the Delay Summary Report section of the PAR report file 
where average delays are listed (beginning with THE AVERAGE 
CONNECTION DELAY for this design), there are two columns 
of figures. The first column gives the actual averages for the 
design. The figures in the second column, which are enclosed by 
parentheses, indicate the averages after the imposition of a tilde 
penalty. 

• The Score For This Design is a rating of the routed design. The 
score is discussed in the "Scoring the Routed Design" section. 

• Timing score is always 0 (zero) if all timing constraints have been 
met. If not, the figure is other than 0 . 
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For the Virtex and Sparlan2 devices, if more than one SeleclIO 
standard is used, an additional section on Select IO utilization and 
usage summary is added to the PAR file. Tills section shows details 
for the different IO banks. It shows the IO standard, the output 
reference voltage (VCCO)| for the bank, the input reference voltage 
(VREF) for the bank, the PAD and Pin names. In addition, the section 
gives a summary for each bank with the number of pads being used, 
the voltages of the VREFs, and the VCCOs. A sample Select IO 
utilization and Usage Summary of the PAR file follows. 

Select IO Utilization and Usage Sunmary 


NR - means Not Required. 

Each Group of a specific Standard is listed. 

IO standard (LVTTL Vref-NR Vcco=3.30) occupies 45 pads. 

IO standard (CTT Vro£=1.50 Vcco=3.30) occupies 8 pads. 

IO standard <SSTL3_I Vrcf=0.90 Vcco=3.30» occupies 12 pads. 


Bank Surrmary 


NR - means Not Required 

Bank 0 has 20 pads and is 80 K utilized. 
Vrcf should be set to MR volts. 

Vcco should be set to 3.30 volts. 


Bank 

Vrcf 


Kamo 

IO 

Select 

Std Vrcf 

Vcco 

Pad 

Pin 

bidir<?> 

IO 

LVTTL 

NR 

3.30 

PAD2 

P238 

bidir<6> 

IO 

LVTTL 

NR 

3.30 

PAD3 

P237 

bidir<3> 

IO 

LVTTL 

NR 

3.30 

PAD8 

P231 

bidir<l> 

IO 

LVTTL 

NR 

3.30 

PAD 10 

P230 

b<10> 

I 

LVTTL 

NR 


PADll 

P229 


b<7> 

I LVTTL 

NR 


PAD 17 

P221 

a< 10 > 

I LVTTL 

NR 


PADlfi 

P220 

1 has 22 pads 

and is 13i utilized. 





should be set 

to NR volts. 





Name 

IO Select Std 

Vrcf 

Vcco 

Pad 

Pin 
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Bank 7 has 21 pads and is 381 utilized. 

Vref should be set to 0.80 volts. 

Vrct' sites in this bank cannot be used tor user IGBs. 
Vcco should be set to 3.30 volts. 


?*an>e 

IO 

Select Std 

Vref 

Vcco 

Pod Pin 

bidir<ll> 

IO 

SSTL3_I 

Cl. 90 

3.30 

PAD169 P28 

bidir<8> 

IO 

SSTL3_I 

Cl. 90 

3.30 

PAD170 P27 

bidir<9> 

IO 

SSTL3_I 

Cl. 90 

3.30 

PAD172 P25 

bidir< 10 > 

IO 

SSTL3_I 

Cl. 90 

3.30 

PAD173 P2«l 

c<9> 

O 

CTT 


3.30 

PAD181 Pi 3 

c< 10 > 

O 

CTT 


3.30 

PAD187 P7 

c<7> 

O 

LVTTL 


3.30 

PAD190 P4 

c<8> 

o 

CTT 


3.30 

PAD!91 P3 


Total BEAL time to Placer completion: <10 secs 
Total CPU time to Placer completion: 31 secs 

For guided par. the PAR report displays summary information 
describing the total amount and percentage of components and 
signals in the input design guided by the reference design. The report 
also displays the total/percentage of components and signals from 
the reference design (guide file) that were used to guide the input 
design. See the "Guide Reporting" section. 

The Delay (DLY) File 

Tine delay file is output by each PAR run and is placed in the 
directory with the NCD output of the design file and the PAR file. 
Tine delay file contains delay information for each net in the design 
and includes the following: 

• A listing of the 20 nets with the longest delays.. In a DLY file, 
maximum delays are preceded by a tilde, indicating that the 
delay shown is only approximate. Following each tilde delay is a 
figure in parentheses. TTnis figure represents the approximate 
delay with a certain percentage automatically added to it (a 
"worst case” situation) when specified by the user in the physical 
constraints (PCF) file. When the Xilinx Development System's 
timing analysis software looks at the delays, it uses the value in 
parentheses rather than the appioximate value represented by 
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the tilde. For more information on the PENALIZE TILDE 
constraint, see the "TRACE" chapter in this manual and the 
"Attributes, Constraints, and Cany Logic" chapter of the Libraries 
Guide. 

• A delay analysis for each net, including the net name, followed 
by the driver pin and the load pin(s). 

The following is a portion of a delay file. If this were a complete file, it 
would show the load delays for all nets in the design. 

Note: The Delay Report is formatted for viewing in a monospace 
(non-proportional) font. If the text editor you use for viewing the 
report uses a proportional font, the columns in the report do not line 
up correctly. 

Fri Mar 12 12:09:41 1999 
File: tcstclk.dly 


The 20 worst nets by delay are: 


Max Delay I Nctnamc I 


6.466 

res 

4.513 

core_inst2/countcrl/C54/N32 

3.985 

outl 

3.577 

cor©_instl/counterl/C9/N32 

3.103 

corc_inst 2 /counter 1 /cont<8> 

3.073 

corc_instl/counterl/cont< 1 > 

3.061 

start 

2.900 

corc_inst 2 /counter 1 /cont<4> 

2.94 4 

cor©_inst 2 /counterl/cont< 2 > 

2.932 

corc_inst 1 /counter 1 /cont<8> 

2.589 

cor©_inst2/counterl/cont<9> 

2.572 

corc_inst2/countcrl/cont<3> 

2.343 

syn2S48 

2.281 

corc_inst 1 /counterl/cont<3> 

2.260 

corc_inst 2 /countcrl/regist 0 < 2 > 

2.247 

cor©_inst 1 /counterl/cont< 0 > 

2.184 

corc_inst2/counterl/rcgist0<9> 

2.160 

core_inst1/counter1/regist0<9> 

2.156 

core_instl/counterl/regist 0 <l> 

2.149 

corc_inst2/counterl/cont<5> 
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Net Delays 


N_ckl_i 

ckl_i.GCLXOUT 

0.001 BUFG_ckl.IN 

N_ck 2 _i 

ck2_i.GCLXOUT 

0.001 BUFG_ck2.IN 

ckl 

BUFG_ckl.OUT 

1.002 corc_instl/counter1/regist0<6>.CLK 
0.992 core_inst1/countorl/rogist1<0>.CLK 
1.002 corc_:nst1/counter1/ ragiflt1 <8>.CLK 


The PAD File 

Tine PAD file contains a listing of all lOBs used in the design and their 
associated pads. The file specifies connections to device pins (with a P 
prefix). 

Tine PAD file is divided into three sections. 

• Tine first section lists the component name in the first column. 
Tine second column of this section lists the designations of the 
device pins. 

• Tine second section lists the pin number in the first column, the 
component name in the second column, and any constraints 
assigned to the component in the third column. 

• Tine third section lists the pinouts in the form of constraints. 
These constraints can be cut and pasted into a PCF file as 
constraints for later PAR runs. 

For 2.1i, the PAD file reports all dual-purpose pins that are used 
during configuration as well during normal operation. 

A sample PAD file is shown following. 
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Note: The PAD Report is formatted for viewing in a monospace 
(non-proportional) font. If the text editor you use for viewing the 
report uses a proportional font, the columns in the report do not line 
up correctly. 

PAR: Xilinx Place And Route 2.1i. 

Copyright <c) 1995-1999 Xilinx, Inc. All rights reserved. 

Fri Mar 12 12:09:42 1999 

Xilinx PAD Specification File 


INPUT FILE: tcstclk.ncd 

OUTPUT FILE: testclk.ncd 

PART TYPE: xcvlQO 

SPEED GRADE: -5 

PACKAGE: Dg256 

Fri Mar 12 12:09:42 1999 


Pinout by Pin Nanc: 



Pin Nanc 

—————————— 

I Direction 

————————— 

1 Pin Number 

ckl_i 


I INPUT 

| BIO 

ck 2 _i 


| INPUT 

| Y10 

cut l__o 


| OUTPUT 

1 Y7 

out 2 _o 


I OUTPUT 

I V8 

ros.i 


I INPUT 

1 Y9 

start_i 


| INPUT 

1 A? 




————————— 


Dedicated or Special Pin Name I Pin Nusher | 


I CCLK 
I CS 
I Dl 


I B19 
I Blfi 
I E20 


VCCO_6 

1 P4 

VCCO_7 

I H4 

VCCOj? 

I G4 

WRITE 

I A19 
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Pinout by Pin Nunbcr: 


— — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — —• 

Pin Number | Pin Name 

-+- 

I Direction 

1 Constraint 

A1 | <TCKJ 

1 

I 

*2 I- 

I UNUSED 

1 

A3 1 — 

| UNUSED 

1 

A4 | 

I UNUSED 

1 


Yl? 

l- 

| UNUSED | 

Y18 

1- 

| UNUSED | 

Y19 

|- 

| UNUSED | 

Y20 

| (PROGRAM) 

1 1 

————— — — — ————— + — — — — — — — — — 


* 

* Pinout constraints listing 

4 These constraints arc in PCF grammar fcrir-at 
I and nay be cut and pasted into the PCF file 

* after the "SCHEMATIC END ;" statement to 

* preserve this pinout for future design iterations. 


* 

CCMP 

"ckl.i* 

LOCATE = 

SITE 

•no* 

COMP 

"ck 2 _i• 

LOCATE = 

SITE 

"BIO* 

CCMP 

"outl_o' 

1 LOCATE - 

= SITE 

"V9* 

CCMP 

"out 2 _o' 

' LOCATE - 

= SITE 

"B9* 

CCMP 

"rcs.i" 

LOCATE = 

SITE 

•BS" 

CCMP 

"start.: 

LOCATE 

= SITE * Y9 

* 






For the Virtex or Spartan2 devices, when SeleclIOs are used, the PAD 
file also contains details of the pads that must be used for the input 
reference voltage (VREF), and those that must be used for the output 
reference voltage (VCCO). For the VREF pads, their location and the 
value of the input reference voltage is shown. A sample Virtex PAD 
file follows. 
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PAR: Xilinx Place And Route 2.1i. 

Copyright <c) 1995-1999 Xilinx, Inc. All rights reserved. 

Fri Mar 12 12:09:43 1999 

Xilinx PAD Specification File 

*VAV#A«A*#A«Aft #AVA*#AV#ftVAV«ft 

Input file: virtex_test.ncd 

Output file: virtcx_test.out.ned 

Part type: xcvSG 

Speed grade: -5 

Package: pq240 

Fri Mar 12 12:09:43 1999 

Pinout by Pin Mane: 

f-♦-f-♦ 

I Pin Name I Direction | Pin Number | 


! INPUT | P97 

INPUT | P99 
I INPUT | Pi03 

I INPUT I Pi13 


I a< 0 > 
I a<l> 
I a< 2 > 
I a<3> 


I Dedicated cr Special Pin Name 

H—- 

I CCLK 
I DONE 
I GND 


vcco 

vcco 

VRBP <0.90V) 
VRBP (0.90VI 
VRBP {0.90VJ 
VRBP <1.S0VJ 
VRBP U.SOV) 


Pinout by Pin Nunber: 
—————————————————————————————————— 

I Pin Number | Pin Name 


Pin Nunber 
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+- 





1 PI 

| GND 


1 

1 

1 P 2 

| THS 


1 

1 

I P9 

I VREF { 0.90V) 

1 


1 

I P36 

| VREF (1.50V* 

1 

1 

1 

I P61 

| VCCO 

-+- 

1 

— ————f——« 

1 

1 


ft 

ft Pinout constraints listing 

ft These constraints arc in PCF granmar format 
ft and nay be cut and pasted into the PCF file 
I after the "SCHEMATIC END statement to 
I preserve this pinout for future design iterations. 

s 


Guide Reporting 

This report, which is included in the PAR report file, is generated 
when using the -gf option. The report describes the criteria used to 
select each component and signal used to guide the design. It may 
also enumerate the criteria used to reject some subset of the 
components and signals that were eliminated as candidates. 

Following is an example of guide file information that displays in the 
PAR file. 

PAH: Xilinx Place And Route 2.1i. 

Copyright <c) 1995-1999 Xilinx, Inc. All rights reserved. 


Mon Mar 15 13:39:04 1999 


par -gn leverage -gf gl.ncd tostclk.ncd guide.ned tcstclk.pcf 


Constraints file: tcstclk.pcf. 

Loading device database for application par from file "tcstclk.ncd". 

•tcst_clock" is an NCD r version 2.29, device xcvlOO, package bg2S6, 
speed -5 

Loading device for application par from file 'vlOO.nph' in environment 
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. ld/bcxfndry/c. 13/rtf. 

Device speed data version: "xl_0.71 1.76 Advanced". 


Loading device database tor application par from file "gl.ncd". 

•tcst_clock' is an NCD, version 2.28, device xcvlOO, package tj g256, 
speed -5 


Starting guide file placement. 


Guide file processing done. 
Guide Summary Report: 


Components: 69 out of 72 964 

Signals: 330 out of 335 994 


Guide File Conponcnts: 69 out of 71 

Placed Guide File Components: 69 out of 

Guide File Signals: 330 out of 330 


97% 

69 

100 % 


100 % 


Guide Detail Report: 


Guidca corrps (Guide Comp) located in the guided site: 

Comp syn2469 lsyn2469) guided to site CLB_R20Cl1.31. 

- Comp successfully guided in matching guide site. 

- Comp names natch in both current and guide design. 

- Comp pins have compatible assignements. 

Comp core_inst2/counter1/C54/C5/C1/D (core_inst2/counterl/C54/C5/Cl/0) 
guided to site CLB_R19C11.SO. 

- Comp successfully guided in matching guide site. 

Guided corrps (Guide comp) unable to be located m the guided site: 


Device utilization sunmary: 


Number 

of 

External 

GCLXIOBs 

2 

out 

of 

4 

50% 

Number 

of 

External 

lOBs 

4 

out 

of 

ISO 

2 % 

Number 

of 

SLICES 


64 

out 

of 

1200 

5% 

Number 

of 

GCLKs 


2 

out 

of 

4 

50% 
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Scoring the Routed Design 

The SCORE FOR THIS DESIGN is a rating of the routed design. The 
PAR file (a portion of which is shown below) shows the total score a* 
well as the individual factors making up the score. The score takes 
the following factors into account (weighted by their relative 
importance). 

• Tire number of unrouted nets (unr) 

• Tire number of timing constraints not met (nest) 

• Tire amount (expressed in ns) that the timing constraints were 
not met (acst) 

• Maximum delay on a net with a weight greater than 3 

• Net weights or priorities 

• Tire average of all of the maximum delays on all nets (av) 

• Tire average of the maximum delays for the ten highest delay 
nets (lOw) 

Tire lower the score, the better the result 
Tlie formula that produces the score is 

5000*unr * 1000'ncst + 20*acst + (delay*weight)*0.2 ♦ av*100 + 
10 w *20 

Tine score in the PAR Report is shown following. 

Note: The PAR file is formatted for viewing in a monospace (non¬ 
proportional) font. If the text editor you use for viewing the report 
uses a proportional font, the columns in the report do not line up 
correctly. 

The Delay Sunmary Report 


The SCORE FOR THIS DESIGH is: 230 

The HUMBER OF SIGNALS HOT COMPLETELY ROUTED for this design is: 0 

The AVERAGE CONNECTION DELAY for this design is: 1.735 

The MAXIMUM PIN DELAY IS: 4.603 

The AVERAGE CONNECTION DELAY on the 10 WORST NETS is: 2.837 

Listing Pin Delays by value: (nsec) 
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d < 1.00 < d < 2.00 < d < 2.00 < d < 4.00 < d < 5.00 d >= 5.00 


5S 127 153 2 6 

riming score: 0 


When a design has been touted to your satisfaction, you can use 
BitGen to produce a bitstream file. 

Turns Engine (PAR Multi-Tasking Option) 

This Xilinx Development System option allows you to use multiple 
systems (nodes) that are networked together for a multi-run PAR job, 
significantly reducing the total amount of time to completion. You 
can specify multi-tasking from the UNIX command line. 

Turns Engine Overview 

Before the Turns Engine was developed for the Xilinx Development 
System, PAR could only run multiple jobs in a linear way. The total 
time required Incomplete PAR was equal to the sum of the times that 
it took for each of the PAR jobs to run. This is illustrated by the 
following PAR command. 

par -1 5 -n 10 -i 10 -c 1 mydesign.ncd output.dir 

The above tells PAR to run 10 place and route passes (-n 10) at effort 
level 5 (-1 5). a maximum of 10 router passes (-i 10), and one cost- 
based cleanup pass (c 1 ). It runs each of the 10 jobs consecutively, 
generating an output NCD file for each job, i.e., output.dir/ 
5_5_l.ncd, output.dir/5 5.2.ncd, etc. If each job takes approximately 
one hour, then the run takes approximately 10 hours. 

Suppose, however, that you have five nodes available. The Turns 
Engine allows you to use all five nodes at the same time, dramatically 
reducing the time required for all ten jobs. To do this you must first 
generate a file containing a list of the node names, one per line as in 
the following example. 

Note: A pound sign (#) in the example indicates a comment. 
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* NODE names 

Jupiter (Fred's node 

macs fHarry's node 

mercury (Betty's node 

ncptunc (Pam's node 

pluto (Mackey's node 

Now run the job from the command line as follows. 

par -m nodefile uame-1 5 -n 10 -i 10 -e 1 mydesign.ncd oulpul.dir 

iiDdefilejumu is fhe name of the node file you created. 

This runs the following jobs on the nodes specified. 

jupiter: par-15-i 10 -c 1 mydesign.ncd oulput.dir/5_5 l.ncd 
mars: par -1 5 -i 10 -c 1 mydesign.ncd output.dir/5_5 2.ncd 
mercuiy: par -15 -i 10 -c 1 mydesign.ncd output.dir/5 J> 3.ncd 
neptune: par -1 5 -i 10 -c 1 mydesign.ncd output.dir/5_5.4.ncd 
pluto: par -1 5 -i 10 -c 1 mydesign.ncd output.dir/5_5_5.ncd 

As the jobs finish, the remaining jobs are started on the nodes until all 
10 jobs are complete. Since each job takes approximately one hour, all 
10 jobs complete in approximately two hours. 

Note: You cannot judge the relative benefits of multiple placements 
by running the Turns Engine with options that generate multiple 
placements but do not route any of the placed designs (the -r PAR 
option specifies "no routing"). The design score you receive is the 
same for each placement. To get some indication of the quality of the 
placed designs, run at least one routing iteration (- 11 ) on each placed 
design. 

Turns Engine Input Files 

The following are the input files to the Turns Engine. 

• NCD File—A mapped design. 

• Nodelist file—A user-created ASCII file listing workstation 
names. A sample nodelist file Ls shown below. 

i This is a corwnent 

* Note: machines arc accessed by Turns Engine 

* from top to bottom 

! Sparc 20 nachincs running Solaris 
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kirk 

spock 

mccoy 

krushcr 

Janeway 

picard 

* Sparc 10 nachincs running SunOS 

michael 

Jcrnainc 

marlcn 

tito 

jackic 

i HPs running HP-UX 

wi Ilian 

gcorgc 

ronald 

jimny 

gorald 

Turns Engine NCD Output File 

Tine naming convention for the NCD file, which may contain 
placement and routing information in varying degrees of completion, 
is placer, level /outerJeveljable.ncd. If any of these elements are not 
used, they are replaced by an 'x'. For example, for the first design file 
being run with the options -n 5 -t 16 -rl 4 -pi 2, the NCD output file 
name would be 2 4 16-incd. The second file would be named 
2 4 17.ncd. For the first design file being run with the options -n 5 -t 
16 -r -pi 2, the NCD output file name would be 2_x_16.ncd. The 
second file would be named 2_x 17.ncd. 

Homogeneous and Heterogeneous Networks 

Tire Tunis Engine can run on the following networks. 

• Homogenous networks—All SunOS, all Solaris, or all HP-UX. 

• Heterogeneous networks—A mix of SunOS, Solaris, and HP-UX. 
You must have the Xilinx software and a license for each plat¬ 
form on which you intend to run. See the sample .eshre file below 
to set up the environment variables. This is possible because the 
nodes read their environment variables from the .eshre file; they 
do not receive them fiom the launching node. 
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Limitations 

Tine following limitations apply to the Turns Engine. 

• Tine Turns Engine can operate only on Xilinx FPGA families. It 
cannot operate on CPLDs. 

• Tine Turns Engine can only operate on UNIX workstations. 

• Each run targets the same part, and uses the same algorithms and 
options. Only the starting point, or the cost table entry, is varied. 

System Requirements 

For 2.1i, there is a new preferred method for setting up system 
requirements. The following two subsections describe each of these 
methods—the new and the old. 

New Preferred Method 

For the new method, you create a file, which can be sourced on 
remote systems, to set up the environment. This file is sourced with 
the Bourne Shell so it must be in the correct format. To source the file, 
follow these steps: 

1. Create a file with a fixed path that can be accessed by all the 
systems you are using. For example. 

/net/S < nodename 1 /home/jim/pacmsetup 

2. Add the lines to set up the XILINX environment variable and the 
path. 

Example for HP systems: 

export XILINX=/net /${node name 1 /home/jim/xilinx 
export PATH=$XILINX/bin/hp: /usr/bin: /usr/sbin 
export SHLIB PATH=$XILINX/bin/hp 

Example for SUN Solaris systems: 

export XILINX=/net/$(mxfi7fdflri‘) /home/jim/xilinx 
export PATH=$XILINX/bin/sol: /usr/bin: /usr/sbin 
export LD LIBRARY PATH=$XILINX/bin/sol 

For mixed sets of systems, you need a more sophisticated script 
that can set up the proper environment. 
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3. After setting up this file, set the environment variable 
PAR M SE7UPFILE to the name of your file. 

Example for C shell: 

setenv PAR M SETUPFILE /n»t/Slnodename] /home/ 
jim/parmsetup 

Example for Bourne or Kom shells: 

export PAR M SETUPFILE=/net/$(nodename) /home/ 
jim/parmsetup; 

Old Method 

Tine following list describes the system requirements for running the 
turns engine. 

• rsh must be located through the path variable. 

• Tine executables required on the systems defined in the nodes file 
are 

• /bin/sh 

• par (must be located through path variable). 

• Tile Turns Engine logs onto a node and then invokes PAR. The 
environment variables on the node are read from the node's 
.cshrc file (or equivalent); they are not passed from the host to the 
node. Therefore, all the Xilinx environment variables below must 
be defined in the .cshrc file. If not, the PAR process on the node 
will not be able to find the software or the licenses. 

• XILINX (points at Xilinx directory structure — must be a 
path accessible to both the machine from which the Turns 
Engine is run and the node). 

• LD LIBRARY PATH (supports par path for shared libraries 
— must be a path accessible to both the machine from which 
the Turns Engine is run and the node). 

• path (contains $XlLINX/bin/$PL.ATFORM, where 
SPLATFORM is one of the following, sun, sol. hp. or rs6000). 

To determine if everything is set up correctly, you can run the rsh 
command to the nodes to be used. Type the following. 

rsh node_name /bin/sh -c par 
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If you gel the usage message back on your screen, everything is set 
correctly. 

Turns Engine Environment Variables 

The environment variables behnv are interpreted by the Turns 
Engine manager. 

• PAR AUTOMNTPT—Specifies the network automount point. 
Tine Turns Engine uses network path names to access files. For 
example, a local path name to a file may be designs/cpu.ncd, but 
tine network path name may be /home/machine.nante/ivan/ 
designs/cpu.ncd or /net/ nmdiine_name/ivan /designs/cpu.ncd. 
Tine PAR.AUTOMNT environment variable should be set to the 
value of the network autonnount point. Tine autonrount points for 
the examples above are /home and /net. The default value for 
PAR.AUTOMNT is /net. 

Tine line beknw sets the automounl point to /nfs. If the current 
working directory is f txsi/user_namef design _name on nixie 
nnynode. the command cd /n £ s/mynode /u s r/ userjmme / 
design .name is generated before PAR runs on the machine. 

setenv PAR AUTOMNTPT /nfs 

Tine setting below does not issue a cd command, you are required 
to enter full paths for all of the input and output file names. 

setenv PAR AUTOMNTPT *“ 

Tine setting below tells the system that paths on the local 
workstation are the same as paths on remote workstations. This 
can be the case if your network does not use an autonnounter and 
all of the mounts are standardized, or if you do use an 
automounter and all mount points are handled generically. 

setenv PAR AUTOMNTPT "/" 

• PAR AUTOMNTTMPPT—Most networks use the/Imp mnt 
temporary mount point. If your network uses a temporary mount 
point with a different name, like /t mnt, then you must set the 
PAR AUTOMNTTMPPT variable to the temporary mount point 
name. In the example above you would set 

PAR AUTOMNTTMPPT to /t mnt. The default value for 
PAR AUTOMNTTMPPT is /Imp mnt. 
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• PAR M DEBUG—Causes the Turns Engine to run in debug 
mode. If the Turns Engine is causing errors that are difficult to 
correct, you can run PAR in debug mode in the following way. 

a) Set the PAR M DEBUG variable. 

setenv PAR M DEBUG 1 

b) Create a node list file containing only a single entry (one 
node). 

This single entry is necessary because if the node list contains 
multiple entries, the debug information from all of the nodes 
is intermixed, and troubleshooting is difficult. 

c) Run PAR with the -m (multi-tasking mode) option. 

In debug mode, all of the output from all commands gener¬ 
ated by the PAR run is echoed to the screen. There are also 
additional checks performed in debug mode, and additional 
information supplied to aid in solving the problem. 

• PAR M SETUPFILE—See the "New Preferred Method” section 
for a discussion of this variable. 

Starting the Turns Engine From the Command Line 

The following is the PAR command line syntax to run the Turns 
Engine. 

par -m nodelistfile -n # ^iterations -a “ .ofjterations to save 
mappedjlesgin. ncd output directory. dir 

-m nodelist file specifies the nodelist file for the Turns Engine run. 

-n # of iterations specifies the number of place and route passes. 

-s #_o/ iterations to save saves only the best -s results. 

mapped design . ncd is the input NCD file. 

output directory . dir is the directory where the best results (-s 
option) are saved. Files include placed and routed NCD, summary 
timing reports (DLY), pinout files (PAD), and log files (PAR). 
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Debugging 

With the Tunis Engine you may receive messages from the login 
process. The problems are usually related to the network or to 
environment variables. 

• Network Problem—You may not be able to logon to the 
machines listed in the nodelist file. 

• Try to ping the nodes by running the following command, 
ping machine jtame 

You should get a message that the machine is alive. Tine ping 
command should also be in your path (UNIX cmd: which 

ping)- 

• Try to logon to the nodes using the command rsh machine_ 
name. You should be able to logon to the machine. If you 
cannot, make sure rsh is in your path (UNIX cmd: which rsh). 
If rsh is in your path, but you still cannot logon, contact your 
network administrator. 

• Try to launch PAR on a node by entering the following 
command. 

rah machine juvne /bin/ah -c par. 

This is the same command that the Turns Engine uses to 
launch PAR. If this command is successful, everything is set 
up correctly for the madtinejuime node. 

• Environment Problem—logon to the node with the problem by 
entering the following UNIX command 

rsh machine name 

Check the SXIL1NX, $LD LIBRARY PATH, and SPATH vari¬ 
ables by entering the UNIX command echo $variable. name. 

If these variables am not set correctly, check to make sure these 
variables are defined in your .cshrc file. 

Note: Some, but not all. errors in leading the .cshrc may prevent the 
lest of the file from being read. These errors may need to be corrected 
befoie the XIL1NX environment variables in the .cslue are read. 
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The error message/bin/ sh: par not found indicates that 
line environment in line .eshre file is nol being correctly read by 
line node. 

Screen Output 

When PAR is running multiple jobs and is nol in nnulli-lasking mode, 
output from PAR is displayed on the screen as the jobs run. When 
PAR is running multiple jobs in multi-tasking mode, you only see 
information regarding the current status of the Turns Engine. For 
example, when the job described in the "Turns Engine Overview” 
section is executed, the following screen output would be generated. 

Starting job 5_5_1 on node jupiter 
Starting job 5_5_2 on node mars 
Starting job 5_5_3 on node mercury 
Starting job 5_5_4 on node neptune 
Starting job 5_5_5 on node pluto 

When one of the jobs finishes, a message similar to the following 
displays. 

Finished job 5_5_3 on node mercury 

These messages continue until there are no jobs left to run. at which 
time "Finished" appears on your screen. 

Note: For HP workstations, you are not able to interrupt the job with 
Control-C as described below if you do not have Control-C set as the 
escape character. To set the escape character, refer to your HP 
manual. 

You may interrupt the job at any time by pressing Control-C. If you 
interrupt the program, you see the following on your screen. 

CONTRL-C interrupt detected. 

Please cheese one of the following options: 

1. Continue processing and ignore the inter¬ 
rupt . 

2. Normal program exit at next check point. 

3. Exit program immediately. 

4. Add a node for running jobs. 

5. Stop using a node. 

6. Display current status. 
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Enter choice - - > 

Choices are described below. 

1. Continue processing and ignore the interrupt—self- 
explanatory. 

2. Normal program exit at next check point—allows the Turns 
Engine to wait for all jobs to finish before terminating. PAR is 
allowed to generate the master PAR output file (PAR), which 
describes the overall run results. 

When you select option 2, a secondary menu appears as shown 
below. 

How would you like to handle the currently 
running job? 

1. Allow jobs to finish. 

2. Halt jobs at next checkpoint. 

3. Halt jobs immediately. 

Enter choice - - > 

a) Allow jobs to finish — current jobs finish but no other jobs 
start if there are any. For example, if you are running 100 jobs 
(-11100) and the current jobs running are 5_5 49 and 5 5 50, 
when these jobs finish, job 5 5 51 is not started. 

b) Halt jobs at next checkpoint — all current jobs stop at the 
next checkpoint; no new jobs are started. 

c) Halt jobs immediately — all current jobs stop immediately; 
no oilier jobs start. 

3. Exit program immediately — all running jobs stop immediately 
(without waiting for running jobs to terminate) and PAR exits the 
Turns Engine. 

4. Add a node for running jobs — allows you to dynamically add a 
node on which you can run jobs. When you make this selection, 
you are prompted as follows. 

Input the name of the node to be added to the 
list 

After you enter the node name, a job starts immediately on that 
node and a "Starling job" message is displayed. 
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5. Slop using a node — allows you to remove a node from the lisl 
so thal no job runs on lhal node. 

If you select Slop using a node, you must also select from the 
following options. 

Which node do you wish to stop using? 

1. jupiter 

2 . mars 

3. mercury 

Enter number identifying the node.(<CR> to 
ignore) 

Enter the number identifying the node. If you enter a legal 
number, you are asked to make a selection from this menu. 

Do you wisli to 

1. Terminate the current job immediately and 
resubmit. 

2 . Allow the job to finish. 

Enter number identifying choice. (<CR> to 
ignore) 

Tine options are described below. 

a) Terminate the current job immediately and resubmit— 
halts the job immediately and sets it up again to be run on the 
next available node. The halted node is not used again unless 
it is enabled by the "add" function. 

b) Allow the job to finish—finishes the node’s current job. 
then disables the node from running additional jobs. 

Note: The list of nodes described above is not necessarily numbered 
in a linear fashion. Nodes that are disabled are not displayed. For 
example, if NODE2 is disabled, the next time "Stop using a node" Is 
opted, the following is displayed. 

Which node do you wish to stop using? 

1 . jupiter 

3. mercury 

Enter number identifying the node. |<CR> to 
ignore) 

6. Display current status — displays the current status of the Turns 
Engine. It shows the state of nodes and the respective jobs. Here 
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is a sample ot what you would see if you chose this option. 


ZD 

NODE 

STATUS 

JOB 

TIKE 

1. 

jupitcr 

Job Running 

5_5_10 

02:30:45 

2. 

urs 

Job Running 

5_5_il 

02:28:03 

3. 

acrcury 

Not Available 



4. 

ncptunc 

Pending Term 

S_5_12 

02:20:01 

5. 

p 1 uto 

Job Running 

5_5_13 

02:20:01 

6. 

venus 

Idle 



7. 

earth 

Job Running 

5_5_12 

25 


Each entry is described below: 

• jupiter has been running job 5.5 10 for approximately 2 1/2 
hours. 

• rsa r s has been running job 5 5 11 for approximately 2 1 /2 
hours. 

• mercury has been deactivated by the user with the "Stop using a 
node" option or it was not an existing node or it was not running. 
Nodes are "pinged” to see if they exist and are running before 
attempting to start a job. 

• nffptun" has been halted "immediately" with job resubmission. 
The Turns Engine is waiting for the job to terminate. Once this 
happens the status is changed to "not available". 

• pi uto has been running job 5_5 13 for 2 hours 20 minutes. 

• venus has finished its current job and is available for another. 
When you see the "Idle" message, it usually means that no other 
jobs am available. 

• earth is running job 5_5 12. This job was resubmitted when 
neptune was dropped. It has been running for 25 seconds. It is 
unlikely that you will see the same job listed twice (as in the 
sample above) since the job pending termination usually finishes 
very quickly. 

There is also a status named "Job Finishing". This appears if the 

Turns Engine has been instructed to halt the job at the next 

checkpoint. 
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Command Line Examples 

Following are a lew examples of PAR command lines and a 
description of what each does. 

Example 1 

Tine following command places and routes the design in the file 
input.ncd and writes the placed and routed design to output.ncd. 

pat input.ncd output.ncd 

Example 2 

Tine following command skips the placement phase and preserves all 
routing information without locking it (re-entrant routing). Then it 
runs up to 999 passes of the router or stops upon completion and 
conformance to timing constraints found in the pref.pcf file. Then it 
runs three delay-based cleanup router passes. If the design is already 
completely routed, the effect of this command is to just run three 
delay-based cleanup passes. 

pat -k -i 999 -c 0 -d 3 input.ncd output.ncd 
pref.pcf 

Example 3 

Tine following command runs 20 place and route iterations at overall 
effort level 3. Tine mapping of the overall level (—ol) to placer effort 
level (-pi) and router effort level (—rl) depends on the device to which 
the design was mapped, and placer level and router level do not 
necessarily have the same value. The iterations begin at cost table 
entry 5. Only the best 3 output design files are saved. The output 
design files (in NCD format) are placed into a directory called 
rcsults.dir. 

par -n 20 -ol 3 -t 5 -s 3 input.ncd 
results.dir 

Now, if you wanted to run two passes of cost-based and delay-based 
cleanup on the three designs saved (without running placement), you 
would enter this command for each design. 

par -k -i 0 -c 2 -d 2 input.ncd output.ncd 
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Example 4 

Tile following command copies the inpul design to the output 
design. The placement and routing phases are skipped completely. 
Since a delay file is generated as a msult of the command, you can use 
these options to check the delay times in your design without having 
PAR change any of the design's placement or routing. 

par -pr input.ncd output.ncd 

Example 5 

Tine following command allows re-entrant routing. Use this 
command when your design is only partially routed and you want to 
complete it or when the design does not meet your timing constraints 
and additional routing passes are needed to meet the constraints. 
Placement and placement optimization are skipped. In this case up to 
30 router passes are run (you could run up to 2000). Tills may result 
in local rip-up and reroute if 20 router passes are run with no 
progress. 

par -k -i 30 input.ncd output.ncd 

Example 6 

The following command gives you a delay report for a placed and 
routed file without modifying the file. 

par -pwr input.ncd input.ncd 

Example 7 

The following command runs PAR (using the Turns Engine) on all 
nodes listed in the file named "allnodes”. It runs 10 place and route 
passes at placer effort level 3 and router effort level 2 on the file 
"mydesign.ncd". It runs one cost-based cleanup pass of the router. 

par -m allnodes -pi 3 -rl 2 -n 10 -i 10 -c 1 
mydesign.ncd output.dir 
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Halting PAR 

Note: You are not able to halt PAR with Control-C as described 
below if you do not have Control-C set as the interrupt character. To 
set the interrupt character, enter stty intr A Y fA C in the .login file or 
.cshic file. 

To halt a PAR operation, enter Control-C. In a few seconds, this 
message appears. 

CNTRL-C interrupt detected. 

Please choose one ot the following options: 

1. Continue processing and ignore the interrupt. 

2 . Ncrnal pregran exit at next check point. 

This will result in saving the best results so far, 
after concluding current processing. 

3 . Exit program immediately. 

4. Display Failing Tinespec Summary. 

5 . Cancel the current 30b and move to the next one at 
the next check point. 

Enter choice —> 

If you have no failing time specifications or are not using the -n 
option. Options 4 and 5 display as follows. 

4. Display Failing Tinespcc $11 mu3 
(Not applicable: Data not available) 

5 . Cancel the current 30b and move to the next one at 
the next check point. 

(Not applicable: Not a nulti-run job.) 

You then select one of the five options shown on the screen. The 
options work in this way. 

• Option 1—this option causes PAR to continue operating as before 
the interruption. PAR then runs to completion. 

• Option 2—this option continues the current place/route iteration 
until one of the following "check points". 

• After constructive placement 

• After the current optimization pass 


12-56 


Xilinx Development System 




PAR—Place anil Route 


• After the current routing iteration 

Tlie system then exits the PAR run and saves an intermediate 
output file containing the results up to the check point. 

If you use this option, you may continue the PAR operation 
at a later time. To do this, you must look in the PAR report 
file to find the point at which you interrupted the PAR run. 
You can then run PAR on the output NCD file produced by 
the interrupted run. setting command line options to 
continue the run from the point at which it was interrupted. 

Option 2 halt during routing may be helpful if you notice 
that the router is performing multiple passes without 
improvement, and it is obvious that the router will not 
achieve 100% completion. In this case, you may want to halt 
the operation before it ends and use the results to that point 
instead of waiting for PAR to end by itself. 

• Option 3—this option stops the PAR run immediately. You do 
not get any output file for the current place/route iteration. You 
do, however, still have output files for previously completed 
place/route iterations. 

• Option 4—PAR displays the contents of the 1TR file on the screen 
and then resumes execution. 

• Option 5 —Terminates current iteration if you have used the -n 
option and continues the next iteration. 

Note: If you started the PAR operation from the Design Manager as a 
background process on a workstation, you must bring the process to 
the foreground using the fg command before you can halt the PAR 
operation. 

After you run PAR, you can use the FPGA Editor on the NCD file to 
examine and edit the results. You can also perform a static timing 
analysis using TRACE or the Timing Analyzer. When the design is 
routed to your satisfaction, you can input the resulting NCD file into 
the Xilinx Development System's BitGen program. BitCen creates 
files that are used for downloading the design configuration to the 
target FPGA. For details on BitGen. see the "BitGen" chapter. 
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This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000HX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

• XC9500/XL 

This chapter describes PIN2UCF. The chapter contains the following 
sections. 

• "PIN2UCF" 

• "P1N2UCF Syntax" 

• , PIN2L'CF Files" 

• "P1N2UCF Options" 

• "P1N2UCF Scenarios' 
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PIN2UCF is a program lhal generates pin locking constraints in a 
UCF file by reading a placed NCD file for FPGAs or C.YD file for 
CPLDs. PIN2UCF writes its output to an existing UCF file. If there is 
no existing UCF file, PIN2UCF creates a new file. 



Figure 13-1 PIN2UCF Flow 

Tine P1N2UCF is used to back-annotate pin locking constraints to the 

UCF file from a successfully placed and routed design (FPGAs) or 

successfully fitted design fCPLDs). 

The following list describes P1N2UCF. 

• The program extracts pin locations and logical pad names from 
an existing NCD or GYD file and writes this information to a 
UCF file. 

• Pin locking constraints are written to a P1NLOCK section in the 
UCF file. The PINLOCK section begins with the statement 
"PINLOCK BEGIN and ends with the statement #PINLOCK 
END. 
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• By default. PIN2UCF does not write conflicting constraints to a 
UCF file. Prior to creating a PIN LOCK section, if PIN2UCF 
discovers conflicting constraints, it writes information to a report 
file, named pinlock.rpt. 

• The pinlock.rpt file has two sections: Constraint Conflicts 
Information and List of Errors and Warnings. 

• Tine Constraints Conflicts Information section does not 
display if there are fatal input errors, for example, missing 
inputs or invalid inputs. However, the created report file 
contains the List of Errors and Warnings. 

• Tine Constraints Conflicts Information section has two 
subsections: 

— Net name conflicts on the pins 
— Pin name conflicts on the nets 

If there are no conflicting constraints, both subsections under 
the Constraint Conflicts Information section contain a single 
line indicating that there are no conflicts. 

• Tine List of Errors and Warnings displays only if there are 
errors or warnings. 

• User-specified pin locking constraints are never overwritten in a 
UCF file. However, if the user-specified constraints are exact 
matches of PIN2UCF generated constraints, a pound sign (#) is 
added in front of all matching user-specified location constraint 
statements. The pound sign indicates that a statement is a 
comment. To restore the original UCF file (the file without the 
PIN LOCK section), remove the PINLOCK section and delete the 
pound sign from each of the user-specified statements. 

• PIN2UCF does not check if existing constraints in the UCF file are 
valid pin locking constraints. 

• P1N2UCF writes to an existing UCF file under the following 
conditions. 

• Tine contents in the PINLOCK section are all pin lock matches 
and there are no conflicts between the PINLOCK section and 
the rest of the UCF file. 

• Tine PINLOCK section contents are all comments and there 
are no conflicts outside the PINLOCK section. 
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• There is no PINLOCK section and no other conflicts in the 
UCF file. 

• Comments inside an existing PINLOCK section are never 
preserved by a new run of PIN2UCF. 

• If PIN2UCF finds a CSTTRANS comment, it equates "INST 
name" to "NET name" and then checks for comments. 


PIN2UCF Syntax 

To invoke P1N2UCF from the UNIX or DOS command line, enter the 
following. 

pin 2 ucf lncd.file.ncd I pin freeze fd t'.qyd\ |-r report fle_name 
-o output ,ucf| 

ncd.fite or pinjreezejile must be the name of an existing file. 

PIN2UCF Files 

Tills section describes the PIN2UCF input and output files. 

Input Files 

Input to P1N2UCF can be either of the following files. 

• NCD file—The minimal requirement is a placed NCD file, but in 
practice you would normally use a placed and routed NCD file 
that meets or is fairly close to meeting timing specifications. 

• C.YD file—The PIN2UCF pin locking utility replaces the old GYD 
file mechanism that was used by CPLDs to lock pins. The C.YD 
file is still available as an input guide file to control pin locking. 
Running P1N2UCF is the recommended method of pin locking to 
use instead of specifying the .GYD file as a Guide file. 

Output Files 

If there is no existing UCF file, PIN2UCF creates one. If a design.ucl 
file Is not specified for P1N2UCF and a UCF file with the same root 
name exists in the same directory as the design file, the program 
appends to that file automatically unless there are constraint 
conflicts. 
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A pinlock.rpl file is written lo the current directory by default. Use 
tlie -r option to write a report file to another directory. 

PIN2UCF Options 

The -o and -r options are the only PIN2UCF option. 

-o (Output File Name) 

-o oulfile[ . ucf| 

Specifies the name of the output UCF file for the design. Tire -o 
option is useful in the following ways. 

• Tire UCF file used for the design has a different root name than 
the design name. By default. PIN2UCF writes a ncdjile.ucf file if 
-o is not specified. You can use this option to write the (append) 
pin locking constraints to the UCF file with a different root name 

• You want lo write a UCF file to a different directory. 

-r (Write to a Report File) 

-t report Jikj\ame 

Writes the PIN2UCF report into the specified report file. If this option 
is not used, then a pinlock.rpl file is automatically written to the 
current directory. 
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PIN2UCF Scenarios 

The following (able describes fhe various P1N2UCF scenarios. 


Scenarios 

PIN2UCF Behavior 

Files 

Created or 
Updated 

User does not have a 

UCF file. 

PIN2UCF creates a UCF file. 

pinlock.rpt 


Writes the pin locking 
constraints to the UCF file. 

design .ucf 

User lias a UCF file. 

P1N2UCF appends the pin 
locking constraints in the 

pinlock.rpt 

There are no pin locking 

P1NLOCK section to the end 

design .ucf 

constraints in the UCF 
file or this file contains 
some user-specified pin 
locking constraints 
outside of thePINLOCK 
section. 

None of the user speci¬ 
fied constraints conflict 
with the PIN2UCF 
generated constraints. 

of the file. 
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Scenarios 

PIN2UCF Behavior 

Files 

Created or 
Updated 

User lias a UCF file. 

P1N2UCF will not write the 
P1NLOCK section. Instead it 

pinlock.rpt 

This file contains some 

exits after providing an error 


user-specified pin 
locking constraints 

message. 


either inside or outside 

Writes a list of conflicting 


of the PINLOCK section. 

Some of the user speci¬ 
fied constraints conflict 
with the PIN2UCF 
generated constraints. 

constraints 


User lias a UCF file. 

PIN2UCF will write a new 
P1NLOCK section in the UCF 

design.ucf 

There are no pin locking 

file after deleting the existing 

pinlock.rpt 

constraints in the UCF 

P1NLOCK section. The 


file. 

contents of the existing 
P1NLOCK section will be 


There is a P1NLOCK 

moved to the new PIN LOCK 


section in the UCF file 
generated from a 
previous run of 

P1N2UCF or manually 
created by the user. 

None of these 

constraints in the 
P1NLOCK section 
conflict with P1N2UCF 
generated constraints. 

section. 
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TRACE 


This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

This chapter describes TRACE®. The chapter contains the following 
sections. 


• "TRACE Syntax" 

• "TRACE Files" 

• "TRACE Options" 

• "Command Line Examples" 

• "TRACE Input Details" 

• "TRACE Output Details" 

• "Halting TRACE" 
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TRACE (Timing Reporter And Circuit Evaluator) provides static 
timing analysis of a design based on input timing constraints. 

Note: On the command line, the TRACE command is entered as 
tree (without an "A"). 

TRACE performs two major functions. 

• Timing verification—the process of verifying that the design 
meets your timing constraints. 

• Reporting—the process of enumerating input constraint 
violations and placing them into an accessible file. TRACE can be 
run on unplaced designs, completely placed and routed designs, 
or designs that are placed and routed to any degree of 
completion. 



Figure 14-1 TRACE 


X7218 


TRACE Syntax 

The following syntax runs TRACE. 

tree [options] design |. ncd| [ct>HSfmi»f| .pcf ]| 

Options can be any number of the TRACE options listed in the 
' TRACE Options" section. They do not need to be listed in any 
particular order. Separate multiple options with spaces. 
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Doftffi| .ncd] is the name of Ihe inpul physical design file. If you 
enter a file name with no extension, TRACE looks for an NCD file 
with the name you specified. 

G>Hsfnrinf| .pcf] specifies Ihe name of a liming physical constraints 
file. This file is used lo define timing constraints for the design. If you 
do not specify a physical constraints file, TRACE looks for one with 
the same root name as the NCD file. 

TRACE Files 

This section describes the TRACE input and output files. 

Input Files 

Input files to TRACE am as follows. 

• NCD file—a mapped design. The type of timing information you 
receive depends on whether the design is unplaced, placed only, 
or placed and routed. 

• PCF file—an optional user-modifiable ASCII Physical 
Constraints File produced by MAP. Tire PCF file contains timing 
constraints used in the TRACE liming analysis. 

Note: The Viewlogic® CAE tools create a file with a .pcf extension 
when generating a plot of a Viewlogic schematic. This PCF file is not 
related to a Xilinx PCF file. Since TRACE automatically reads a PCF 
file with the same root name as your design file, make sure your 
directory does not contain a Viewlogic PCF file with the same root 
name as your NCD file. 

Output Files 

Output from TRACE is a timing report (TWR) file. There are three 
different types of timing reports: summary report, error report, and 
verbose report. The type of report produced is determined by the 
TRACE command line options you enter, as shown in the following 
table. 


Development System Reference Gitiite 


14-3 




Development System Reference Guide 


Table 14-1 TRACE Options and Reports 


TRACE Option 

Report Produced 

No -e or -v 

Summary report 

-e 

Error report 

-V 

Verbose report 


TRACE Options 

This section describes the options to the TRACE command. 

-a (Advanced Analysis) 

The -a option can only be used if you are not supplying any timing 
constraints (in a PCF file) to TRACE. The -a option writes out a 
timing report containing the following. 

• An analysis that enumerates all clocks and the required OFFSETS 
for each clock. 

• An analysis of paths having only combinatorial logic, ordered by 
delay. 

This information is supplied in place of the default information for 
the output timing report type (summary, error, or verbose). 

If you want to perform an advanced analysis and you have timing 
constraints, then move the PCF file to another directory or rename 
the PCF file to a name other than the input design name. Remember 
to replace the PCF file when you are finished. 

-dfs (Thorough timing analysis of paths) 

Tire -dfs option specifies that TRACE utilize depth-first search timing 
analysis, which analyzes all paths covered by timing constraints in 
order to perform timing-driven place and route. This method is more 
thorough than the default method and may result in longer TRACE 
runtimes. See the -kpaths option for a discussion of the connection- 
based method. 
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-e (Generate an Error Report) 

-e I/wirtl 

Tile -e option generates an emir report. The report has the same root 
name as the input design and a .twr extension. You can assign a 
different root name for the report on the command line, but the 
extension must be .twr. 

The limit is an integer limit on the number of items reported per 
constraint. The integer limit can be used to limit the number of items 
reported for each timing constraint in the report file (the default is 3 
items). 

-f (Execute Commands File) 

-f command Jile 

The -f option executes the command line arguments in the specified 
command_file. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-kpaths (Faster Analysis of Paths) 

The non-enumerative connection-based method (the default) lias a 
runtime proportional to the size of the design, unlike the DFS 
method, which has a runtime proportional to the number of patlis in 
the design. 

There are two significant differences between the connection-based 
method and the DFS method. 

• The DFS method analyzes all paths except those that actually 
contain a circuit cycle, including paths that contain connections 
that cause a circuit cycle for other paths in the circuit. The 
connection-based method may not analyze these paths 
depending on circuit topology. The TRACE timing report 
contains a list of design connections that cause circuit cycles. The 
connection-based timing analysis may give more optimistic 
results for designs that have long paths with connections that 
cause circuit cycles. 

Consider the following example circuit. 
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Figure 14-2 Circuit Cycles 

The DFS method traces the path from IN. through A. through the 
signal LOOP, back to the left-most logic block and to the signal 
OUT. The new connection-based method may not trace this path 
because a combinatorial cycle exists at the output of A. 

• The DFS method removes false paths from a design that requires 
contending instate enable signals. The connection-based method 
does not perform this optimization, which means that it may 
analyze some paths that an? statically faLse based on tristale 
enable signals. The connection-based timing analysis may give 
more pessimistic results of designs that contain static false paths. 

Consider tire following circuit. 
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Figure 14-3 Trislale Buffer Paths 

A signal can pass through lour pa tils in the preceding circuit, but two 
of the paths are false (A1 to B2 and B1 to A2). In order for a signal to 
pass through the upper left trislale buffer Al, the enable signal A 
must be true. In order to prevent a bus contention on the A 1 output, 
tile enable signal B must be false. Since buffer B2 is also controlled by 
tlie enable signal B, the path through Al cannot pass through B2 
(because when A is enabled, B is disabled). The converse is also true, 
if B is enabled, the only valid path is from B1 to B2. 

In the example circuit, the DFS method only considers true paths. The 
connection-based method will trace the fake patlis and the true 
pa Ills. 

-o (Output File Name) 

-O OUlflh'l . t*fl| 

Tlie -o option specifies the name of the output timing report. The .twr 
extension is optional. 
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-s (Change Speed) 

-s |s/v«f| 

The -s option overrides (he device speed contained in (he input NCD 
file and instead performs an analysis for the device speed you specify. 
Tlie -s option applies to whichever report type you produce in this 
TRACE run. Tlie option allows you to see if faster or slower speed 
grades meet your timing requirements. 

Tlie device speed can be entered with or without the leading dash. For 
example, both -s 3 and -s -3 are valid entries. 

Some architectures support minimum timing analysis. The command 
line syntax for min timing analysis is: tcace -s min. Do not place a 
leading dash before min. 

Note: The -s option only changes the speed grade for which the 
timing analysis is performed; it does not save the new speed grade to 
the NCD file. 

-skew (Analyze Clock Skew for All Clocks) 


This -skew option analyzes clock skew for all docks including those 
using non-dedicated clock routing resources. 

-stamp (Generates STAMP timing model files) 

-stamp slampfile design . ncd 

When you specify the -stamp option, TRACE generates a pair of 
STAMP timing model files slampfile. mod and slampfile.dMa that 
characterize the design's timing. 

Note: A slampfile entry is required before the NCD file entry for the 
2.11 release. 

Tlie STAMP compiler can be used for any board when performing 
static timing analysis. 

There are four methods of running TRACE with the STAMP option 
to obtain a complete STAMP model report. 
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• Run with advanced analysis (-a) 

• Run using default analysis (that is, with no constraint file and 
without advanced analysis). 

• Construct constraints to cover all paths in the design. 

• Run using the unconstrained path report (-u option) for 
constraints which only partially cover the design. 

For either of the last two options, you should not have any path 
controls or TICs or be aware that those paths are not part of the 
model. 

-u (Report Uncovered Paths) 

Tire -u option reports delays for paths that are not covered by tinring 
constraints. The option adds an "Unconstrained path analysis" 
constraint to your existing constraints. This constraint performs a 
default path enumeration on any paths for which no other constraints 
apply. The default path enumeration includes circuit paths to data 
and clock pins on sequential components and data pins on primary 
outputs. 

In the TRACE report, the following is included for the 
"Unconstrained path analysis" constraint. 

• Tire minimum period for all of the uncovered paths to sequential 
components. 

• Tire maximum delay for all of the uncovered paths containing 
only combinatorial logic. 

• For a verbose report only, a listing of periods for sequential paths 
and delays for combinatorial paths. Tire list is ordered by delay in 
descending order, and the number of entries in the list can be 
controlled by specifying a limit when you enter the -v (Generate 
a Verbose Report) command line option. 

-v (Generate a Verbose Report) 

-V [frmi'fl 

Tire -v option generates a verbose report. Tire report has the same 
root name as the input design and a .twr extension. You can assign a 
different root name for the report on the command line, but the 
extension must be .twr. 
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The limit variable is an integer limit on the number of items reported 
per constraint. The integer limit can be used to limit the number of 
items reported for each timing constraint in the report file (the default 
is 3 items). 

Command Line Examples 

Tlie following command verifies the timing characteristics of the 
design named designl.ncd. generating a summary timing report. 
Timing constraints contained in the file groupl.pcf are the timing 
constraints for the design. This generates the report file designl.twr. 

tree designl.ncd groupl.pcf 

Tine following command produces a file listing all delay 
characteristics for the design named designl.ncd, using the timing 
constraints contained in the file groupl.pcf. Tine verbose report file is 
called output.twr. 

tree -v designl.ncd groupl.pcf -o output.twr 

Tine following command analyzes the file designl.ncd and reports on 
the three worst errors for each constraint in timing.pcf. The report is 
called design l.twr. 

tree -e 3 designl.ncd timing.pcf 

TRACE Input Details 

Input to TRACE is a mapped NCD design and an optional physical 
constraints (PCF| file based upon tinning constraints that you specify. 
Constraints can indicate such things as clock speed for input signals, 
the external liming relationship between two or more signals, 
absolute maximum delay on a design path, or a general timing 
requirement for a class of pins. 
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TRACE Output Details 

TRACE output is an ASCII timing report file that enables you to see 
how well the timing constraints lor the design have been met. The file 
is written into your current working directory and has a .twr 
extension. The default name for the file is the same root name as the 
NCD file. You can designate a different root name for the file, but it 
must have a .twr extension. The extension .twr is assumed if not 
specified. 

Tile timing report lists statistics on the design, any detected timing 
emus, and a number of warning conditions. 

Timing errors indicate absolute or relative timing constraint viola¬ 
tions. These include the following. 

• Path delay errors—where the path delay exceeds the maximum 
delay constraint for a path. 

• Net delay errors—where a net connection delay exceeds the 
maximum delay constraint for the net. 

• Offset errors—where either the delay offset between an external 
clock and its associated data-in pin is insufficient to meet the 
internal logic's timing requirements or the delay offset between 
an external clock and its associated data-out pin exceeds the 
external logic's timing requirements. 

• Net skew errors—where skew between net connections exceeds 
the maximum skew constraint for the net. 

Timing errors may require design modifications, running PAR, or 

both. 

Warnings point out potential problems such as circuit cycles or a 
constraint that does not define any paths. 

Three types of reports are available. You determine the report type by 
entering the appropriate option entry on the UNIX or DOS command 
line or by selecting the type of report from the Timing Analyzer (see 
the "TRACE Options" section). Each type of report is described in the 
"Reporting with TRACE" section. 
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Timing Verification with TRACE 

TRACE checks the delays in Ihe NCD design file against your timing 
constraints. II delays are exceeded. TRACE issues the appropriate 
timing error. 

Net Delay Constraints 

Tire delay for a constrained net is checked to ensure that the 
constraint is equal to or greater than the routedelay. 

constraint 2 routedelay 

routedelay is the signal delay between the driver pin and the load 
pin(s) on a net. This is an estimated delay if the design is placed but 
not routed. 

Any nets showing delays that do not meet this condition generate 
timing errors in the timing report. 

Net Skew Constraints 

Signal skew on a net with multiple load pins is the difference 
between minimum and maximum load delays. Skew is checked 
against the specified maximum skew for constrained nets in Ihe PCF 
file. 

constraint 2 (maxdelay - mindelay) 

maxdelay is the maximum delay between the driver pin and a load 
pin. 

mindelay is the minimum delay between the driver pin and a load 
pin. 

If the skew is found to exceed the maximum skew constraint, the 
timing report shows a skew error. 

Path Delay Constraints 

The delay through a constrained path is checked to insure that the 
constraint is greater than or equal to the sum of logic (component) 
delay, route (wire) delay, and setup time (if any), minus clock skew 
(if any). 

constraints logicdelay + routedelay + setuptime-clockskew 


14-12 


Xilinx Development System 




TRACE 


logicdelay is the pin-lo-pin delay through a component. 

routedelay Ls the signal delay between component pins in a path. 
This is an estimated delay if the design is placed but not routed. 

seluptime (for clocked paths only) is the time that data must be 
present on an input pin before the arrival of the triggering edge of a 
clock signal. 

clockskew (for register-to-register chicked patlvs only) is the 
difference between the amount of time the clock signal takes to reach 
the destination register and the amount of time the clock signal takes 
to reach the source register. Clock skew is discussed in the following 
section. 

Patlvs showing delays that do not meet this condition generate timing 
errors in the timing report. 

Clock Skew and Setup Checking 

Clock skew must be accounted for in register-to-register setup 
checks. For register-to-regisler paths, the data delay must reach the 
destination register within a single clock period for the destination 
register. The timing analysis software ensures that any clock skew 
between the source and destination registers is accounted for in this 
check. 

Note: In default mode, that is, without using the -skew option, only 
dedicated clock resource skew accounting is performed. With the 
-skew option, non-dedicated clock skew accounting is also 
performed. 

A setup check performed on register-to-register paths checks the 
following condition. 

Slack = constraint + Tsk - fTpalh + Tsu) 

constraint is the required time interval for the path, either specified 
explicitly by you with a FROM TO constraint, or derived from a 
PERIOD constraint. 

Tpath is the summation of component and connection delays along 
the path (including Ihe Tcko delay from Ihe source register). 

Tsu is the setup requirement for the destination register. 

Tsk is the difference between the arrival time for Ihe destination 
register and the source register. 
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Negative slack indicates that a setup error may occur, because the 
data from the source register does not set up at the target register for 
a subsequent clock edge. 

In the following figure, the clock skew Tsk is the delay from the clock 
input (CLKIOB) to register D (TclkD) less the delay from the clock 
input (CLKIOB) to register S (TelkS). Negative skew relative to the 
destination reduces the amount of time available for the data path, 
and positive skew relative to the destination register is truncated to 
zero. 



XB260 


Figure 14-4 Clock Skew Example 

Because the total clock path delay is used to determine the clock 
arrival times at the source register (TclkS) and the destination register 
(TclkD). this check still applies if the source and destination clocks 
originate at the same chip input but travel through different clock 
buffers and/or routing resourees. as shown in the following figure. 



Figure 14-5 Clock Passing Through Multiple Buffers 

When the source and destination clocks originate at different chip 
inputs, no obvious relationship between the two clock inputs exists 
for the timing software (because the software cannot determine the 
clock arrival time or phase information). 
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For FROM TO specifications, the software assumes you have taken 
into account the external timing relationship between the chip inputs. 
Tile software assumes both clock inputs arrive simultaneously, and 
the difference between the destination clock arrival time (TclkD) and 
the source clock arrival time (TdkS) does not account for any 
difference in the arrival times at the two chip clock inputs. 



Figure 14-6 Clocks Originating at Dilferent Device Inputs 

The clock skew Tsk is not accounted for in setup checks covered by 
PERIOD constraints when; the clock paths to the source and 
destination registers originate at different clock inputs. 

Reporting with TRACE 

The timing report produced by TRACE is an ASCII file prepared for a 
particular design. It reports statistics on the design, a summary of 
timing warnings and errors, and optional detailed net and path delay 
reports. 

Note: All TRACE reports are formatted for viewing in a monospace 
|non-proportional) font. If the text editor you use for viewing the 
reports uses a proportional font, the columns in the reports do not 
line up correctly. 

This section covers the three different types of timing reports 
generated by TRACE. They are as follows. 

• The summary report—Contains summary information, design 
statistics, and statistics for each constraint in the PCF file. 

• The error report—Lists timing errors and associated net/path 
delay information. 


Dezvlopmenl System Reference Guide 


14-15 






Development System Reference Guide 


• The verbose report—Lists delay information for all nets and 
pa tits. 

In each type of report, the header specifies the type of report, the 
input design name, the optional input physical constraints file name, 
and device and speed data for the input NCD file. At the end of each 
report is a timing summary, which includes the following 
information. 

• The number of timing errors found in the design. This 
information appeals in all reports 

• A timing score, showing the total amount of error (in picosec¬ 
onds) for all timing constraints in the design 

• Tine number of paths and nets covered by the constraints 

• Tine number of route delays and the percentage of connections 
covered by tinning constraints 

Note: The percentage of connections covered by timing constraints is 
given in a "% coverage" statistic. The statistic does not indicate the 
percentage of pa tins covered; it indicates the percentage of 
connections covered. Even if you have entered constraints that cover 
all paths in the design, this percentage may be less than 100 %, since 
some connections are never included for static timing analysis (for 
example, connections to the STARTUP component). 

• Tine number of nets covered by constraints 

• A list of global statistics for the design 

In the following sections, a description of each report is accompanied 
by a sample. 

Following are some additional notes about timing reports. 

• For any of the three types of reports, if you specify a physical 
constraints file that contains invalid data, a list of physical 
constraints file errors appears at the beginning of the report. 
These include errors in constraint syntax. 
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• In a TRACE report, a tilde (-) preceding a delay value indicates 
that the delay value is approximate. Values with the tilde cannot 
be calculated exactly because of excessive delays, resistance, or 
capacitance on the net, that is, the path is too complex too 
calculate accurately. 

The tilde <-) also means that the path may exceed the numerical 
value listed next to the tilde by as much as 20%. You can use the 
PENALIZE TILDE constraint to penalize these delays by a 
specified percentage (see the "Attributes, Constraints, and Carry 
Logic" chapter of the Libraries Guide for a description of the 
PENALIZE TILDE constraint). 

• In a TRACE report, an “R" appended to a delay value indicates 
the value was calculated for a rising signal, and an "F” indicates 
the value for a falling signal. If rising and falling values an? 
different, TRACE reports the appropriate delay. 

• TRACE detects when a path cycles (that is, when the path passes 
through a driving output more than once), and reports the total 
number of cycles detected in the design. When TRACE detects a 
cycle, it disables the cycle from being analyzed. If the cycle itself 
is made up of many possible mutes, each mute is disabled for all 
pa tils which converge through the cycle in question and the total 
number is included in the reported cycle tally. 

A path is considered to cycle outside of the influence of other 
paths in the design. Thus if a valid path follows a cycle from 
another path, but actually converges at an input and not a 
driving output, the path is not disabled and will contain the 
elements of the cycle which may be disabled on another path. 

• In Xilinx FPC.As,455 tristate buffer (TBUF) outputs are always 
muted on longlines. Pullup resistors may also be tied to these 
longlines. The timing effects of a TBUF/pullup combination is 
handled differently in the various FPGA architectures. 

• In XOOOOA/L, XC3100A/L. 400I1E/L, XC5200. and Spartan/ 
XL designs, the delay associated with the longline is built 
into the component delay for the TBUF. and is not included 
in the delay reported for the net on the longline. 
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• In XC4000EX/XL/XV designs, the net delay on the longline 
is computed and reported as if the pullup (and not the TBUF 
output) is driving the net. If you want the delay to be 
computed with the TBUF driving the net, do not include any 
pullups at the output of the TBUF. 

• Error counts for both -dfs and -kpaths reflect the number of path 
endpoints (register setup inputs, output pads) that fail to meet 
timing specifications, not the number of paths that fail the specifi¬ 
cation. Consider the following circuit. 



X8360 

Figure 14-7 Error Reporting 

If an error is generated at both the endpoints of A and B, the timing 
report would list two errors—one for each endpoint. 
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Data Sheet Reports 

In 2-Li, the summary, error, and verbose reports contain a data sheet 
report. This report only include IOs that are covered by the specified 
physical timing constraints, if any. A warning is issued if the report 
does not cover any IOs of the design due to the specified timing 
constraints. In the absence of a physical constraint file, all IO timing is 
analyzed and reported (less the effects of any default path tracing 
controls). Unconstrained path analysis can be used with a constraint 
file to increase the coverage of the report to include paths not 
explicitly specified in the constraints file. The report includes the 
source and destination PAD names, and either the propagation delay 
between the source and destination or the setup and hold 
requirements for the source relative to the destination. This report 
summarizes the following delay characteristics for the design: 

• External setup/hold requirements 

The maximum setup and hold times of device data inputs are 
listed relative to each clock input. When two or more paths from 
a data input exist relative to a device clock input, the worst-case 
setup and hold times are reported. One worst-case setup and 
hold time is reported for each data input and clock input 
combination in the design. 

Following is an example of an external setup/hold requirement 
in the data sheet report: 


Setup/Hold to clock ckl_i 


Source Pad 

—+- 

| Setup to | 

| elk ledge) | 

Held to 
elk ledge) 

start_i 

1 2.816(R)| 

— + - 

0.000(R) 


• Clock-to-output propagation delays 

Tine maximum propagation delay from clock inputs to device 
data outputs are listed for each clock input. When two or more 
paths from a dock input to a data output exist, the worst-case 
propagation delay is reported. One worst-case propagation delay 
is reported for each data output and dock input combination. 

Following are two examples of clock-to-output piopagation 
delays in the data sheet report: 
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Clock ckl_i to Pad 


I elk ledge) | 
Destination Padl to PAD | 


outl_o 

1 16.691<R»| 

-+-+ 

Clock to Setup 

on destination clock ck 2 _i 

Dost | 

Source Clock 

Fell | 

I Src/Destl Src/Dest| Src/Dest| Src/ 

I Rise/Rise|Fa11/Rise|Rise/Fall 1 Fa11/ 

ck 2 _i 

ckl_i 

1 12.647| | | 

1 10.2411 I I 


• Input-to-output propagation delays 

The maximum propagation delay from each device input to each 
device output is reported if a combinational path exists between 
the device input and output. When two or moie paths exist 
between a device input and output, the worst-case propagation 
delay is reported. One worst-case propagation delay is reported 
for every input and output combination in the design. 

Following are examples of input-to-output propagation delays: 


Pad to Pad 


Source Pad 

|Destination Padl 

- 

Delay | 

BSLOT0 

|D0& 

1 

37.534 

BSLOTl 

|D09 


37.076 

BSLOT2 

1 DIO 

1 

34.627 

BSLOT3 

1 D11 

1 

37.214 

CRESETN 

|VCASNO 

1 

51.046 

CRESETN 

|VCASNl 

1 

51.046 

CRESETN 

|VCASN2 

1 

49.776 

CRESETN 

|VCASN3 

1 

52.400 

CRESETN 

|VCASN4 

1 

52.314 

CRESETN 

|VCA3NS 

1 

52.314 

CRESETN 

|VCASN6 

1 

51.357 

CRESETN 

|VCASN7 

1 

52.527 


-+-- 
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There die lour methods of running TRACE to obtain a complete data 
sheet report. 

• Run with advanced analysis (-a) 

• Run using default analysis (that is, with no constraint file and 
without advanced analysis) 

• Construct constraints to cover all paths in the design 

• Run using the unconstrained path report for constraints which 
only partially cover the design 

For either of the last two options, you should not have any path 
controls or TIGs or be aware that those paths will not be pail of the 
report. 

Guaranteed Setup and Hold Reporting 

Guaranteed setup and hold values obtained from speed files are used 
in the data sheet reports for lOB input registers when these registers 
are clocked by specific clock routing resources and when the 
guaranteed setup and hold times are available for a specified device 
and speed. 

Specific clock routing resources are clock networks that originate at a 
clock IOB, use a clock buffer to reach a clock routing resource and 
route directly to IOB registers. 

Guaranteed setup and hold times are also used for reporting of input 
OFFSET constraints. 

Tile following figure and text describes the external setup and hold 
time relationships. 
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Figure 14-8 Guaranteed Setup and Hold 

The pad CLKPAD of clock input component CLKIOB drives a global 
clock buffer CLKBUF. which in turn drives an input flip-flop IFD. 
Tire input flip-flop IFD docks a data input driven from DATAPAD 
within the component lOB. 


Setup Times 

Tire external setup time is defined as the setup time of DATAPAD 
within IOB relative to CLKPAD within CLKIOB. When a guaranteed 
external setup time exists in the speed files for a particular 
DATAPAD and the CLKPAD pair and configuration, this number is 
used in timing reports. When no guaranteed external setup time 
exists in the speed files for a particular DATAPAD and CLKPAD 
pair, the external setup time is reported as the maximum path delay 
from DATAPAD to the IFD plus the maximum IFD setup time, less 
the minimum of maximum path delay(s) from the CLKPAD to the 
IFD. 


Hold Times 


Tire external hold time is defined as the hold time of DATAPAD 
within IOB relative to CLKPAD within CLKIOB. When a guaranteed 
external hold time exists in the speed files for a particular DATAPAD 
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and the CLKPAD pair and configuration, this number is used in 
timing reports. 

When no guaranteed external hold time exists in the speed files for a 
particular DATAPAD and CLKPAD pair, the external hold time is 
reported as the maximum path delay from CLKPAD to the 1FD plus 
the maximum 1FD hold time, less the minimum of maximum path 
delay(s) from the DATAPAD to the IFD. 

Summary Report 

Tire summary report includes the name of the design file being 
analyzed, the device speed and report level, followed by a statistical 
brief that includes the summary information (timing errors, etc. 
described above) and design statistics. The report also list statistics 
for each constraint in the PCF file, including the number of timing 
errors for each constraint. 

A summary report is produced when you do not enter an -e (error 
report) or -v (verbose report) option on the TRACE command line. 

Two sample summary reports are shown below. The first sample 
shows the results without having a physical constraints file. The 
second sample shows the results when a physical constraints file is 
specified. 

If no physical constraints file exists or if there are no timing 
constraints in the PCF file, TRACE performs default path and net 
enumeration to provide timing analysis statistics. Default path 
enumeration includes all circuit paths to data and clock pins on 
sequential components and all data pins on primary outputs. Default 
net enumeration includes all nets. 

Note: The summary report is formatted for viewing in a monospace 
(non-proportional) font. If the text editor you use for viewing the 
report uses a proportional font, the columns in the report do trot line 
up correctly. 

Summary Report (Without a Physical Constraints File Specified) 

Tire following sample summary report represents the output of this 
TRACE command. 

tree -o surreaary. twr tcstclk.ncd 
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The name of the report is summary.twr. No preference file Ls speci¬ 
fied on the command line, and the directory* containing the file 
testclk.ncd did not contain a PCF file called testclk.pcf. 


Xilinx TRACE, Version 2.ii 

Copyright <c> 1995-1999 Xilinx# Inc. Ail rights reserved. 


Design file: testclk.ncd 

Physical constraint file: testclk.pcf 

Device,speed: xcvlOO,-5 |C 1.1.2.4 Advanced} 

Report level: sumnary report 


WARNING:Timing - No timing constraints found, doing default enumeration. 


Asterisk (*) preceding a constraint indicates it was not net. 


Constraint 

| Requested | Actual 

| Logic 


1 1 

1 Levels 

Default period analysis 

I I 13.321ns 

1 12 

Default net cnumcration 

I I 4.724ns 

ft 


Ail constraints were net. 
Data Sheet report: 


All values displayed in nanoseconds InsJ 


Setup/Hold to clock ckl_i 


Source Pad 

—+-+ . 

| Setup to | 

| elk ledge) | 

Held to 
elk ledge) 

start_i 

1 2.316 (R)| 

.— + -*- 

0.000 <R) 


Clock ck2_i to Pad 
—— ————————— ————+———————————— 

I elk ledge) | 
Destination Padi to PAD | 
-,-» 
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out2_o I 12.fi20<R)| 

-+- 4 


Clock ckl_i to Pad 

-+-4. 

| elk ledge) | 
Destination Pad| to PAD | 


outi_o I 15.066<R)| 

-4- 4 . 

Clock to Setup on destination clock ck2_i 

- 4 - 4 - 4 - 4 - 4 

| Sre/Dest| Sre/Dest| Sre/Dost| Sre/Dest| 
Source Clock |Rise/Rase|Fall/Rise|Rise/Fal1|Fal1/Fall| 

-4- 4 - 4 - 4 - 4 

ck2_i I 12.6471 I I I 

ckl_i I 10.2411 I I I 

- 4 - 4 - 4 - 4 - 4 

Clock to Setup on destination clock ckl_i 

- 4 - 4 -4-4-4 

I Sre/Dest| Sre/Dest| Sre/Dest | Sre/Dest| 
Source Clock IRisc/Rise|Fall/Rise|Rise/Fal11Fal1/FallI 


ckl_i | 13.1991 | | I 

- 4 - 4 - 4 - 4 - 4 

Timing surrmary: 


Timing errors: 0 Score: 0 

Constraints cover 2124 paths, 136 nets, and 300 connections (100.0% 
coverage) 

Design statistics: 

Mi imum period: 13.321ns iMaxinun frequency: 75.069MHz) 

Maximum combinational path delay: 13.630ns 
Maximum net delay: 4.724ns 


conpletcd Mon Mar 29 07:17:41 1999 


Development System Reference Guide 


14-25 
















Development System Reference Guide 


Summary Report (With a Physical Constraints File Specified) 

The following sample summary report represents the output of this 
TRACE command. 

tree -o sucoaryl. twr testcllc.ncd testcllc.pcf 

The name of the report is summary l.twr. The timing analysis 
represented in the file were performed by referring to the constraints 
in the file testclk.pcf. 


Xilinx TRACE, Version 2.1i 

Copyright <c> 1995-1999 Xilinx* Inc. Ail rights reserved. 

Design file: testclk.ncd 

Physical constraint file: testclk.pcf 

Device,speed: xcviOO,-5 |C 1.1.2.4 Advanced* 

Report level: sumnary report 


Asterisk 

(*) preceding a 

constraint indicates it was 

not net. 


Constraint 



1 Requested 

1 

| Actual 

1 

1 Logic 

I Levels 

TS_ckl_i 

HIGH 

= PERIOD 

50.000 4 

TIMEGRP 

*ckl_i" 20 nS 

1 20 . 000 ns 

1 

1 13.321ns 

1 

1 12 

1 

TS_ck2_i 

HIGH 

= PERIOD 

50.000 4 

TIMEGRP 

*ck2_i" IS nS 

I 18 . 000 ns 

1 

I 12.653ns 

1 

1 11 

1 

OFFSET = 

IN 20 nS 

BEFORE 

COMP "ckl.i" 

1 20 . 000 ns 

I 2 . 816 ns 

1 2 

OFFSET = 

OUT IS nS 

AFTER 

COMP # ckl_i" 

! 18 . 000 ns 

I 15.086ns 

1 s 

OFFSET = 

IN 22 nS 

BEFORE 

COMP •ck2_i* 

1 

1 

1 

OFFSET - 

OUT 17 nS 

AFTER 

COMP # ck2_i" 

, 17.000ns 

I 12 . 820 ns 

1 5 


Ail constraints were net. 


Data Sheet report: 


Ail values displayed in nanoseconds InsJ 


14-26 


Xilinx Development System 


















TRACE 


Setup/Hold to 

clock ckl_i 


Source Pad 

T “ *T 

| Setup to | 

| elk ledge) | 

Hold to 
elk ledge) 

start_i 

“T* 

1 2.816 <R|| 

0.000(R» 


Clock ck2_i to Pad 



1 

elk ledge) 

Destination 

Padl 

to PAD 

out 2 _o 

1 

12.320(R) 

Clock ckl.i 

to Pad 


1 

elk ledge) 

Destination 

Padl 

to PAD 

outl_o 

1 

15.0&6<R) 


Clock to Setup on destination clock ck2_i 

-4-4-4-4-4 

| Sre/Dest) Sre/Dest | Sre/Dest | Sre/Dest| 
Source Clock |Rise/Risc|Fall/Risc|Rase/FallIFall/Fall| 


ck2_i I 12.647| | | | 

ckl_i I 10.2411 I I I 

- 4 - 4 - 4 - 4 - 4 

Clock to Setup on destination clock ckl_i 

- 4 - 4 - 4 - 4 - 4 

| Sre/Dest| Sre/Dest | Sre/Dest| Sre/Dest| 
Source Clock |Risc/Rise|Fall/Rise|Rise/Fall|Fall/Fall| 

- 4 - 4 - 4 - 4 - 4 

ckl_i I 13.1991 | | | 

-4-4-4-4-4 


Timing summary: 


Timing errors: 0 Score: 0 
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Constrairts cover 2124 paths, 0 nets, and 346 connections <91.6% coverage) 
Design statistics: 

Minimum period: 13.321ns iMaxixnm frequency: ?5.069MHz) 

Minimurri input arrival time before clock: 2.616ns 

Minimum output required tine after clock: 15.096ns 


conpleted Won Mar 29 07:00:11 1999 


When the physical constraints file includes timing constraints, the 
summary report lists the percentage of all design connections 
covered by timing constraints. If there are no timing constraints, the 
report shows 100 percent coverage. An asterisk precedes constraints 
that fail. 

Error Report 

Tine error report lists timing errors and associated net/pa tin delay 
information. Errors are ordered by constraint and. within constraints, 
by slack (the difference between the constraint and the analyzed 
value, with a negative slack indicating an error condition). Tine 
number of errors listed for each constraint is set by the limit you enter 
on the command line. The error report also contains a list of all time 
groups defined in the PCF file and all of the members defined within 
each group. 

Tine main body of the error report lists all timing constraints as they 
appear in the input PCF file. If the constraint is met. the report simply 
states the number of items scored by TRACE, reports no timing errors 
detected, and issues a brief report line, indicating important 
information (for example, the maximum delay for the particular 
constraint). If the constraint is not met. it gives the number of items 
scored by TRACE, the number of errors encountered, and a detailed 
breakdown of the error. 

For errors in which the path delays are broken down into individual 
net and component delays, the report lists each physical resource and 
the logical resource from which the physical resource was generated. 

As in the other three types of reports, descriptive material appears at 
the top. A timing summary always appears at the end of the report. A 
sample error report follows. 
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Note: The error report is formatted for viewing in a monospace (non- 
proportional) font. If the text editor you use for viewing the report 
uses a proportional font, the columns in the report do not line up 
correctly. 

Sample Error Report 

Tlie following sample error report (error.twr) represents the output 
of this TRACE command. 

tree -o error3.twr -e 3 test.clock.ncd 


Xilinx TRACE, Version 2.1i 

Copyright <c) 1995-1999 Xilinx, Inc. All rights reserved. 

Design file: testclk.ncd 

Physical constraint file: tcstclk.pcf 

Device,speed: xcvlQO,-5 |C 1.1.2.4 Advanced) 

Report level: error report, limited to 3 items per constraint 


Timing constraint: TS_ckl_i = PERICO TIMEGR? *ckl 


i ; 

955 items analyzed, 0 timing errors detected. 
Minimum period is 13.186ns. 


20 nS HIGH 50.000 


Timing constraint: OFFSET = OUT 12 nS AFTER COMP •ckl^i" 


12 items analyzed, 3 tining errors detected. 
Minimum allowable offset is 13.152ns. 

Slack: -1.152ns path cki_i to outl.o relative to 



1,240ns delay cki_i to corc_inst1/counter 1/r agist 0<0> and 
11.904ns delay cor©_insti/ccuntcrl/regist0<0> to outi_o and 
12 . 000 ns offset ckl_i to outl_o 


Clock path ckl_i to cor©_instl/counterl/regist0<0> contains 2 levels of 
logic: 

Path starting from Conp: Yll.PAD 

To Delay type Delay(ns) Physical Resource 

Logical Resource(s) 
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Yll.GCLXOUT 

Tgpid 

0.728R 

ckl.i 
ckl.i.PAD 

C-ckU 

GCLKEUFQ.IN 

net (fanout=l) 

0.007R 

H-ckU 

GCLKECFO. COT 

Tgio 

0.077R 

BUFG.ckl 
BUFG.ck1 

CLB_R20C8.S0.CLX 

net <fanout= 16 ) 

0.436R 

ckl 

Total (0.SOSns logic 
|64.5% logic. 

, 0.443ns route) 
3S.5% route) 

1.248ns 



Data path core.instl/counterl/registO<0> to outl.o contains 5 levels of 
logic: 

Path starting from Coup: CLB.R20Cft.S0.CLK (from ckl) 


To 

Delay ;ypc 

Delay(ns) 

Physical Resource 
Logical Resource Is) 

CLS.R2 0C&.SO.XQ 

Tcko 

1.147R 

> 




eg< 0 > 

CLB.R19C8.S1.G1 

net (fanout=4) 

1.413R 

> 

CLB.R19C8.S1 

Tilo 

0.622R 

syn2458 

C386 

CLB.R18C9.S0.G1 

net (fanout=l) 

1.237R 

syn2458 

CLB.R18C9.S0.Y 

Tilo 

0.622R 

out 1 

CLB_R18C9.S0.F3 

net (fanout=l) 

0.093R 

syn632 

CLB.R18C9.SO.X 

Tilo 

0.622R 

out 1 




C383 

Y6 .O 

net <fanout=ll) 

1.722R 

out 1 

Y6.PAD 

Tioop 

4.426R 

out 1.0 

OEUF.out1 
outl.o.PAD 

Total |7.439ns logi< 

4.48Sns route) 

11.904ns 


182 .5% logic. 

37.5% route) 




Slack: -0.997ns path ckl.i to outl.o relative to 

1.248ns delay ckl_i to core.inst1/counter1/rcgistQ<0> and 
11.749ns delay core.instl/counterl/rcgist0<0> to outl.o and 
12 . 000 ns offset ckl.i to outl.o 
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Timing constraint: OFFSET - ZN 22 nS BEFORE COMP ■ck2^i“ ; 
0 itens analyzed, 0 timing errors detected. 


Timing constraint: OFFSET = OUT 17 nS AFTER COMP 
12 items analyzed, 0 tising errors detected. 
Minimum allowable offset is 13.034ns. 


•ck 2 _i H 



1 constraint not met. 


Data Sheet report: 


All values displayed in nanoseconds Ins) 


Setup/Hold to clock ckl_i 


Source Pad 

| Setup to I 
| elk (edge) | 

— — —— — — — — — — — —T 

Held to | 

elk ledge) | 

start..i I 2.957 (R) | 

Clock ck2_i to Pad 

-+-+ 

| elk ledge) | 
Destination Pad| to PAD | 

0.000(R)| 

-+ 

out 2 _o 

1 13.034<R|| 


Clock to Setup 

on destination 

clock ckl_i 

Source Clock 

I Src/Dcst| Src/Dcst| Src/Dcst| Src/Dcst 

I Rise/Rise|Fall/Rise|Rise/Fal11Fall/Fall 

ckl_i 

QBSSBl 

i i 


Table of Tinegroups: 


TimeGroup ckl__i: 

BELs: 

corc_i ns 11 /count cr 1 / registl_rcg< 0 > core_inst 1 /counter 1 /rcgist l_reg<l> 
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st 1 /countcrl/registl_rcg< 2 > 

corc_inst1/counter1/registl_rcg<3> corc_inst1/counter1/registl_reg<4> 
st1/counter1/registl_rog<5> 


TimeGroup ck2_i: 

BELs: 

core_inst 2 /counter 1 / registl_rcg< 0 > corc_inst 2 /counter 1 /regist l_reg<l> 
st 2 /counter 1 /registl_rcg< 2 > 

core_inst2/counter1/ registl_rcg<3> corc_mst2/countcr 1 /regist l_reg<4> 
st2/countcrl/registl_rcg<5> 


core_inst 2 /counterl/cont_reg<?> core_inst 2 /countcrl/cont_reg< 8 > 

st2/countcrl/ccnt_rcg<9> 

Timing s urinary: 


Timing errors: 3 Score: 24 5“ 

Constraints cover 2124 paths, 0 nets, and 348 connections <91 .61 coverage) 
Design statistics: 

Minimum period: 13.186ns (Maximus frequency: 75.838MHx) 

Minimum input arrival time before clock: 2.957ns 

Minimum output required tine after clock: 13.152ns 

Analysis conpleted Tue Mar 30 07:40:08 1999 
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Verbose Report 

The verbose report is similar to the error report, providing more 
details on delays (or all constrained paths and nets in the design. 
Entries are ordered by constraint and, within constraints, by slaek. 
The number of items listed for each constraint is set by the limit you 
enter on the command line. 

Note: The data sheet report and STAMP model display skew values 
on non-dedicated clock resources that do not display in the default 
period analysis of the normal verbose report. The data sheet report 
and STAMP model must include skew because skew affects the 
external timing model. To display skew values in the verbose report, 
use the -skew option. 

Tine verbose report also contains a list of all time groups defined in 
the PCF file, and all of the members defined within each group. 

As in the other types of reports, descriptive material appears at the 
top. 

Tine body of the verbose report enumerates each constraint as it 
appears in the input physical constraints file, the number of items 
scored by TRACE for that constraint, and the number of errors 
detected for the constraint- Each item is described, ordered by 
descending slack. A Report line for each item provides important 
information, such as the amount of delay on a net and by how much 
the constraint is met. 

For path constraints, if there is an error, the report indicates the 
amount by which the constraint is exceeded. For errors in which the 
path delays are broken down into individual net and component 
delays, the report lists each physical resource and the logical resource 
from which the physical resource was generated. 

If there are no errors, the report indicates that the constraint passed 
and by how much. Each logic and route delay is analyzed, totaled, 
and reported. 

Note: The verbose report is formatted for viewing in a monospace 
(non-proportional) font. If the text editor you use for viewing the 
report uses a proportional font, the columns in the report do trot line 
up correctly. 
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Sample Verbose Report 

The following sample verbose report (verbose.twr) represents the 
output of this TRACE command. 

tree -o verbosel.twr -v 1 testclk.ncd 


Xilinx TRACE, Version 2.1i 

Copyright <c> 1995-1999 Xilinx, Inc. All rights reserved. 

Design file: testclk.ncd 

Physical constraint file: testclk.pcf 

Device,speed: xcvlQO,-5 |C 1.1.2.4 Advanced} 

Report level: verbose report, limited to 1 item per constraint 


Timing constraint: 

% ; 


TS ckl i = PERICO TIHEGR? *ckl 


95S items analyzed, 0 timing errors detected. 
Minimum period is 13.121ns. 


20 nS HIGH 50.000 


Slack: 6.679ns path core.inst1/counterl/cont<l> to core.inst1/counter1/ 
cont<9> relative to 

13.260ns delay constraint 
0 . 061 ns clock skew 
20 . 000 ns delay constraint 

Path core.inst1/counterl/rcgist0<0> to ccrc_instl/countcrl/cont<9> 
contains 12 levels of logic: 

Path starting from Coup: C1B.R19C6.S1.CLK (from ckl) 

To Delay type Delay(ns) Physical Resource 

Logical Resource Is) 


CLB.Rl9C6.SO.rO Tcko 


CLB.R17C6.S1.XQ net fanout=4) 

CLB.R17C6.S1.CCXIT Tcpcyt 


1.147R core.inst1/counter1/ 
/rcgist 0 < 0 > 
core.inst 1 /counterl/ 
/regist 0 .reg< 0 > 

2.422R > 

1.246R O 

C371 

core.inst1/counter1/C9 
/C2/C1 

core.inst1/counterl/C9 
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TRACE 


/C3/C1 


CLB_Rl7c5.S0.F3 not <fanout=l) 1.267R corc_inst1/counter1 

/N362 

CLB_JU?C5.S0.CLK Tick 1.024R ccrc_inst1/counter1/ 

cont<9> 

C303 

core_inst 1 /countcrl/ 
cont_reg<9> 


Total |6.052ns logic, 7.208ns route) 13.260ns {to ckl) 

145.6% logic, 54.7% routeJ 


Ail constraints were net. 

Data Sheet report: 

All values displayed in nanoseconds Ins J 


Setup/Hold to clock ckl_i 


Source Pad 

—+ - 

| Setup to | 

| elk ledge) | 

Hold to 
elk ledge) 

start_i 

1 2.816<RM 

— * - ♦- 

0.000(R» 


Clock ck2_i to Pad 


| elk ledge) | 
Destination Pad| to PAD | 


out2_o I 12.820(R)| 

-+-f 

Clock ckl_i to Pad 

- + - + 

| elk ledge) | 
Destination Pad| to PAD | 
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-+- 4 

outi_o I 15.086<R| | 

-X-X 


Clock to Setup on destination clock ck2_i 


Source Clock 

-4-4-4-4 

I Src/Dcst| Src/Destl Src/Dcst| 

IRisc/RiselFell/Rise|Risc/Fall| 

Src/Dcst 
Fa11/Fall 

ck 2 _i 

ckl_i 

1 12.6471 I I 

1 10.2411 1 I 


Clock to Setup 

on destination clock ckl_i 


Source Clock 

| Src/Destl Src/Dest| Src/Dcst| 

IRisc/RisclFall/Rise|Risc/Fall| 

Src/Dest 

Fall/Fall 

ckl_i 

1 13.1991 I I 

-4-4-4-4 

SB 


Table of Tincgroups: 

TimeGroup ckl__i: 

BELs: 

corc_inst 1 /counterl/ registl_reg< 0 > 
core_inst1/counterl/registl_reg<3> 
corc_inst 1 /counterl/registl_rcg<6> 
core.inst1/countcr1/registl_reg<9> 
corc_inst 1 /counter 1 /regist 0 _rcg< 2 > 
corc_inst 1 /countcr 1 /regist0_rcg<5> 
corc_i ns 11 /count cr 1 / rcgistG..rcg<&> 
corc_inst 1 /counterl/cont_reg<Q> 
corc_inst 1 /counter 1 /ccnt_rcg<l> 
corc_inst1/counterl/cont_rcg<3> 
corc_inst 1 /counter 1 /ccnt_rcg<4> 
corc_inst 1 /counterl/cont — reg<6> 
corc_inst 1 /counter 1 /ccnt_reg<7> 
core_inst 1 /counterl/cont_reg<9> 

TimeGroup ck2_i: 

BELs: 

corc_inst 2 /counter 1 /registl_reg< 0 > 
core.inst 2 /counter 1 /registl_reg<3> 


core.instl/counterl/rcgistl_rcg<l> > 
core.instl/counterl/rcgistl_rcg<4> > 
corc^inst1/counter1/rcgistl_rcg<7> > 
core.inst1/counter1/rcgistG_rcg<0> > 
core.inst1/counter1/rcgistG — reg<3> > 
core.inst1/counter1/rcgi5tG_rcg<6> > 
core_inst 1 /counterl/regist0_rcg<9> 

core.inst 1 /counterl/cont_reg< 2 > 

core_inst1/countcrl/cont_rcg<5> 

core.inst 1 /counterl/cont_reg<8> 


core.inst 2 /counter 1 /regist 1 — rcg<l> > 
core.inst 2 /countcrl/regist 1 _rcg<4> > 
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TRACE 


corc_inst 2 /counter 1 /regist 1 _reg<6> 
corc_inst 2 /counterl/registl_reg<9> 
core_inst 2 /counter 1 /regist 0 _rcg< 2 > 
core_inst2/counterl/regist0_reg<5> 
corc_inst 2 /counter 1 /rcgistG_rcg<8> 
core_inst 2 /countcr 1 /cont_reg< 0 > 
core.inst 2 /counter 1 /ccnt_reg< 1 > 
core_inst2/counterl/cont_reg<3> 
core_inst 2 /counter 1 / ccnt_reg<4> 
core.inst 2 /counterl/cont_reg<6> 
core_inst2/counter1/ccnt_rcg<7> 
core_inst2/counterl/cont_reg<9> 

Timing surrmary: 


corc_ mst2/countc r 1 / regist l_rcg<7> > 
core_inst 2 /countcrl/rcgist 0 _rcg< 0 > > 
ccre_inst2/counterl/rcgist0_rcg<3> 
corc_inst 2 /countcr 1 /rcgistG_rcg<6> > 
core__i ns t 2 /count cr 1 / regi s 10 _rcg< 9> 

ccre_inst 2 /counterl/cont_rcg< 2 > 

ccre_inst2/counterl/cont_reg<5> 

core_inst 2 /counterl/cont_rcg<8> 


Timing errors: 0 Score: 0 

Constraints cover 2124 paths, 0 nets, and 348 connections (91.61 coverage) 
Design statistics: 

Minimum period: 13.321ns (Maxinun frequency: 75.069MHz) 

Minimum input arrival time before clock: 2.816ns 

Minimum output required tine after clock: 1 : j . 086ns 
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Halting TRACE 

To hall TRACE, enter CO.NTROL-C (on a workstation) or 
CONTROL-BREAK (on a PC). On a workstation, make sure that 
when you enter CONTROL-C. the active window is the window 
from which you invoked TRACE. The program prompts you to 
confirm the interrupt. Some files may be left when TRACE is halted 
(for example, a TRACE report file or a physical constraints file), but 
these files may be discarded because they represent an incomplete 
operation. 
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SPEEDPRINT 


This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL//XLA/XV 

• XC5200 

• Spartan/XL/2 

• Virtex 

The chapter contains the following sections. 

• 'SPEEDPRINT -1 

• "SPEEDPRINT Syntax" 

• "SPEEDPR1 NT Options" 

• "Example Commands" 

• "Example Outputs" 

SPEEDPRINT 

SPEEDPRINT lists important block delays for a specific device's 
speed grade in a convenient tabular format of an ASCII file. The 
program is not intended to replace data sheets, but rather should be 
used as a supplement. The SPEEDPRINT program reports devices 
and speed grades installed on your system. 

For detailed information, see the The Programmable Logic Data Boot or 
the data sheets at the Xilinx web site. 
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X8849 

Figure 15-1 SPEEDPRINT 

SPEEDPRINT Syntax 

Tine following syntax runs speedprint. 

speedprint [options] device name 

options can be any number of the SPEEDPRINT options listed in any 
order. Make sure to separate multiple options with spaces. See the 
next section for a description of these options. 

To display a description of the SPEEDPRINT command and its 
options, enter speedprint or speedprint -h. 
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SPEEDPRINT Options 

This section describes the options to the SPEEDPRINT command. 

-min (Display Minimum Speed Data) 

-min 

The -m option displays minimum speed data for a device. This 
option overrides the -s option if both are used. 

-s (Speed Grade) 

-a [speed.grade] 

Tine -s option with a speed grade argument (for example, -4) displays 
data for the specified speed grade. If the -s option is omitted, delay 
data for the default, which is the fastest speed grade, is displayed. 

-t (Specify Temperature) 

-t temperature 

Tine -t option specifies the operating die tennperatuie in degree. 
Celsius. If this option is omitted, the worst-case temperature is used. 

-v (Specify Voltage) 

-V !Y>/fll£C 

Tine -v option specifies the operating voltage of the device in volts. If 
this option is omitted, the worst-case voltage is used. 
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Example Commands 


The following table describes some example commands. 


Command 

Description 

speedprint 

Prints usage message 

speedprint xc4044xl 

Uses the default speed grade 

speedprint -s -3 xc4044xl 
speedprint -s 3 xc4044xl 

Both commands display block 
delays for speed grade -3 

sptvdprinl -v 3.0 -140 xc4044xl 

Uses default speed grade at 3.0 
volts and 40 degrees C 

sptvdprinl -s min xc4044xl 
sptvdprinl -min xc4044xl 

Both commands display data for 
(he minimum speed grade. 


Example Outputs 

Following is the first part of a speed grade report for the XC4044XL 
device. Tlie following command generates the displayed report. 

speedprint xc4044xl 

The default speed grade, temperature, and voltage settings are 
described at the beginning of the file. 

Block delay report tor a: x4044xl 
Speed grade is: -09 

Version id for speed file is: xl_0.4S 1.24 PRELIMINARY xilinx 


This speed file supports voltage adjustments over the range of 3.000000 to 
3.600000 volts. 

Temperature adjustments arc supported over the junction terrperature range 
of 0.000000 to 85.000000 degrees Celsius 

This report prepared for default temperature and voltage. 

Note - this report is intended to present the effect of different 
specdgradcs and voltage/tcnperaturc adjustments on block delays, for 
specific situations use the timing analyzer report instead. 

Delays are reported in picoseconds, where a range of delays is given they 
represent the fastest and slowest paths reported under that nano. 
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When a block is placed in a site normally used for another typo of block. 

a IGB placed in a Clock 
may occur which are not 

IOB site for 
included in i 

example, small variations in delay 
:his report. 

External Setup and Hold 

requirenerts 

for global clocks 


Tpfhen 4300 

Tpfhep 

0 

Tpfsen 

300 

Tpfaep 10200-10800 

Tphd 

0 

Tphed 

0 

TPhen 4300 

Tphep 

0 

Tphn 

3800 

Tphp 0 

Tpsd 

6B00 

Tpaed 

9100 

Tpaen 300 

Tpsp 3600 

Tpsep 

10200-10800 Tpan 

800 

Delays for a CLB 

Tab 2000 

Tahds 

0 

Tabs 

0 

Taht 2000 

Taht a 

0 

Taa 

1959-2430 

Tasc+Taa 3760 

Taac+Taaa 

34 60 

Taac+Taat 

3760 

Taac+Taata 3460 

Tasc+Tick 

2 670 

Taac+Tihck 

3440 

Tasc*Tiho 3760 

Taac+Tihto 

4410 

Taac+Tiio 

2989 

Tasc*Tito 3639 

Taacy 

1 BOO 

Taada 

1660-2130 

lass 1660-2130 

Tast 

1950-2430 

Taata 

1650-2130 

Tbyp 140 

Tebyp 

929 

Tekd 

0 

Tekdi 0 

Tekdt 

0 

Tekee 

0 

TckhhO 0 

Tckhhl 

0 

Tckhh2 

0 

Teki 0 

Tekih 

0 

Tekk 

-7080-5410 

Teko 1470 

Tekr 

0 

Teto 

1680 

Delays for a IOB 

• 

• 

• 

• 

Tchio 2300 

Tekpi 

0 

Tckpic 

0 

Tekpid 0 

Tekpide 

0 

Tekpisn 

0 

Tekpitne 0 

Tekpia 

0 

Tckpiac 

0 

Tekpiad 0 

Tekpiade 

0 

Tekpa 

0 
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Tckpsc 

0 

Tckpsd 

0 

Tckpsdc 

0 

Tecik 

60 

Tecok 

-190 

Tikec 

0 

Trpo 

18050 

Trri 

18390 

Ttshz 

4100 

Ttshz 

4100 

Ttsonf 

3300 

Ttsonfc 

4150 

Ttsons 

5000 

Ttsonsc 

5850 



Delays for 

a TBUF 





Tio 

470 

Toff 

600 

Ton 

800 
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Chapter 16 


BitGen 


This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

This chapter describes BitGen. The chapter contains the following 
sections. 

• "BitGen" 

• "BitGen Syntax" 

• "BitGen Files" 

• "BitGen Options" 

BitGen 

BitGen produces a bitstream for Xilinx device configuration. After the 
design has been completely routed, it is necessary to configure the 
device so that it can execute the desired function. This is done with 
BitGen, Xilinx's bitstream generation program. BitGen takes a fully 
routed NCD (Circuit Description) file as its input and produces a 
configuration bitstream—a binary file with a .bit extension. 
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The BIT file contains all of the configuration information from the 
NCD file defining the internal logic and interconnections of the 
FPGA, plus device-specific information from other files associated 
with the target device. The binary data in the BIT file can then be 
downloaded into the FPGA's memory cells or it can be used to create 
a PROM file (see the "PROMGen" chapter). 



Figure 16-1 BitGen 


X7217 
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BitGen Syntax 

Tlie following syntax creates a bitstream from your NCD file. 

bitgen [options] infiie] .ncd] [oulfile] [pcfjile | 

options is one or more of the options listed in the "BitGen Options" 
section. 

Infile is the name of the NCD design for which you want to create the 
bitstream. You may specify only one design file, and it must be the 
first file specified on the command line. 

You do not have to use an extension. If you do not, .ncd is assumed. If 
you do use an extension, it must be .ncd. 

Out/ile is the name of the output file. If you do not specify an output 
file name, BitGen creates one in the input file’s directory. If you 
specify -1 on the command line, the extension is .11 (see -1 command 
line option). If you specify -m (see -m command line option), the 
extension is .msk. If you specify’ -b, the extension is .rbt. Otherwise 
the extension is .bit. If you do not specify an extension. BitGen 
appends one according to the aforementioned rules. If you do include 
an extension, it must also conform to the rules. 

Pcfjile is the name of a physical constraints (FCF) file. BitGen uses 
this file to determine which nets in the design are critical for tiedown 
(see the ”-t (Tie Unused Interconnect)" section). BilGen automatically 
mads the .pcf file by default. If the physical constraints file is the 
second file specified on the command line, it must have a .pcf 
extension. If it is the third file specified, the extension is optional; .pcf 
is assumed. If a .pcf file name is specified, it must exist, otherwise the 
input design name with a .pcf extension is read if that file exists. 

A report file containing all of BitGen's output is automatically created 
under the same directory as the output file. The report file has the 
same root name as the output file and a .bgn extension. 
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BitGen Files 

Tlio inpul tiles that BilGen requires and Ihe output tiles that BitGen 

generates are described below. 

Input Files 

Input to BitGen consists ot the following tiles. 

• NCD file—a physical description of the design mapped, placed 
and routed in the target device. The NCD file must be fully 
routed. 

• PCF—an optional user-modifiable ASCII Physical Constraints 
File. If you specify a PCF file on the BitGen command line. 
BitGen uses this file to determine which nets in the design are 
critical for tiedown (see the ~-t (Tie Unused Interconnect)" 
section). 

Output Files 

Output from BitGen consists of the following files. 

• BIT tile—a binary tile with a hit extension. The BIT tile contains 
all ot the configuration information from the NCD file delining 
the internal logic and interconnections of the FPGA. plus device¬ 
specific information from other files associated with the target 
device. The binary data in the BIT file can then be downloaded 
into the FPGA’s memory cells or it can be used to create a PROM 
file (see the "PROMGen" chapter). 

• RBT file—an optional "rawbits" file with an .rbt extension. The 
rawbits file consists of ASCII ones and zeros representing the 
data in the bitstream file. If you enter a -b option on the BilGen 
command line, an RBT file is produced in addition to the binary 
BIT file (see the "-b (Create Rawbits File)” section). 

• LL file—an optional ASCII logic allocation file with an .11 
extension. The logic allocation file indicates the bitstream 
position of latches, flip-flops, and IOB inputs and outputs. An LL 
file is produced if you enter a -I option on the BilGen command 
line (see the "-1 (Create a Logic Allocation File)" section). 
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• MSK file—an optional mask file with an .msk extension. This file 
is used to compare relevant bit locations for executing a readback 
of configuration data contained in an operating FPGA. A MSK 
file is produced if you enter a -m option on the BitGen command 
line (see the “-m (Generate a Mask File)" section). 

• BGN file—a report file containing information about the BitGen 
run. 

• DRC file—a Design Rule Check (DRC) file for the design. A DRC 
runs and the DRC file is produced unless you enter a -d option 
on the BitGen command line (see the "-d (Do Not Run DRC)" 
section). 

BitGen Options 

Following is a description of the command line options and how they 
affect the behavior of BitGen. 

Note: For a complete description of the Xilinx Development System 
command line syntax, see the "Command Line" section of the 
"Introduction" chapter. 

Options for the BitGen command are as follows. 

-a (Tie All Interconnect) 

Used with the -t option to force tiedown to fail if all nodes are not 
tied. This option also allows tiedown to implement user signals. 

-b (Create Rawbits File) 

Create a "rawbits" {file rwi/ic.rbt) file. The rawbits file consists of 
ASCII ones and zeros representing the data in the bitstream file. 

If you are using a microprocessor to configure a single FPGA, you 
can include the rawbits file in the source code as a text file to repre¬ 
sent the configuration data. The sequence of characters in the rawbits 
file is the same as the sequence of bits written into the FPGA. 
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-d (Do Not Run DRC) 

Do no! run DRC (Design Rule Check). Without the -d option, BitGen 
runs a DRC and saves the DRC results in two output files: the BitGen 
report file (file _name.bgn) and the DRC file (file name.dtc). If you 
enter the -d option, no DRC infnimation appears in the report file 
and no DRC file is produced. 

Running DRC before a bitstream is produced detects any errors that 
could cause the FPGA to malfunction. If DRC does not detect any 
errors, BitGen produces a bitstream file (unless you use the -j option 
described in the "-j (No BIT File)" section). 

You cannot disable the DRC with the -d option if you have specified 
a -t (Tie Unused Interconnect) option. The DRC always runs if you 
specify -t. 

-f (Execute Commands File) 

-f command Jilt 

Tine -f option executes the command line arguments in the specified 
command Jite. For more information on the -f option, see the "-( 
Option" section of the "Introduction" chapter. 

-g (Set Configuration) 

The -g option specifies the startup timing and other bitstream 
options for Xilinx FPGAs. The settings for the -g option depend on 
the design's architecture. These settings are described in the 
following sections. 

• "-g (Set Configuration—XC3X00 Devices)" 

• "-g (Set Configuration—XC4000 and Spartan)" 

• "-g (Set Configuration—XC5200 Devices)" 

• "-g (Set Configuration—Virtex and Spartan2 Devices)” 

-g (Set Configuration—XC3X00 Devices) 

Tine -g option has sub-options that represent settings you use to set 
the configuration for an XC3XOOA/L design. These options have the 
following syntax. 
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bitgen -g option:selling 

For example, lo set Ihe inpul signal thresholds lo CMOS level instead 
of TTL level, use the following syntax. 

bitgen -g inputs:CMOS 

Tile following sections describe the startup sequences for the -g 
option applied to an XC3X00 design. 

DonePin 

Enables or disables internal pull-up on the DOME/PKtK.RAM (D/P) 
pin. The Pullnone setting indicates there is no connection to the pull- 
up. 

Use this option only if you are planning to connect an external pull- 
up resistor to this pin. The internal pull-up resistor has a value of 2 to 
8 kli and is automatically connected if you do not use this option. 
Tine D/P pins configure an open-drain driver that requires a pull-up 
resistor to indicate the end of the configuration. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Pullup. Pullnone 

Default: Pullup 

DoneTime 

Releases the DONE.TKOt.RAM (D/P) pin one Cdk cycle before the 
IOBs become active (Before setting) or one Cclk cycle after the IOBs 
become active (After setting). 

Tine After setting clearly indicates the end of the configuration 
process. Tine Before setting can be used to de-activate external 
configuration drivers so that they do not contend with active outputs 
on the same pin. The use of After would create a 1-Cclk-period 
contention. The alternative, using the LDC output, might cause a 
short contention spike. Before avoids these problems. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Before. After 

Default: Before 
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Input 

This option sets the FPGA design Input-signal thresholds to TTL or 
CMOS level for interface capability. CMOS improves noise immunity 
and reduces static power consumption. 

Tire special-purpose dock inputs, TCLK1N, BCLKIN, and PWKUN 
always require CMOS-level signals, even if the FPGA design input 
thresholds are specified as TTL compatible. 

Architectures: XC3000A/L, XC3100A/L 

Settings: TTL. CMOS 

Default: TTL 


LC_Alignment 

Determines how length count is calculated to control when the device 
changes from configuration to user operation. The two methods of 
calculating length count. DONE Alignment and Length Count 
Alignment, are discussed in The Programmable Logic Data Book. The 
FPGA Configuration Guidelines Application Note also contains length 
count information. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Length. DONE 

Default: Length 

Oscillator 

This option specifies crystal oscillator options for XC3XOO series 
devices. The crystal oscillator is associated with the auxiliary clock 
buffer in the lower-right corner of the die. 

Tire Disable option disables the FPGA crystal oscillator. Enable 
enables it. The EnableDiv2 option enables the oscillator and divides 
the crystal output frequency by two in order to guarantee a 
symmetrical clock signal. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Disable. Enable. EnableDiv2 

Default: Disable 
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ReadBack 

This option specifies readback options for XC3X00 families. After the 
FPGA design has been configured, the FPGA configuration data can 
be read back and compared with the original configuration data. 
Readback is initiated by a Low-to-High transition on the M0/KTR1G 
pin. Once you give the readback command, external logic must drive 
the Cdk input to read back each data bit. The readback data appears 
on the RlJAl A pin. 

The Disable option disables readback. The Once option enables a one¬ 
time readback and Command enables readback on command. 

Tine Disable and Once options are used for design security. The Once 
option allows only one readback, typically performed during 
manufacturing. After this, readback can never be invoked again. 

If the FPGA device is powered by a standby battery and the 
configuration source is removed, the FPGA design configuration data 
is completely secure from being read or copied. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Conenand. Disable. Once 

Default: Cocreiand 

ResetTime 

Removes INTERN AL RESET one clock cycle before or one clock cycle 
after the lOB becomes active. 

When you specify the After setting, the outputs go active while all 
internal flip-flops are still being held in Reset. When you specify the 
Before setting, the internal logic becomes operational before the 
outputs go active. 

Architectures: XC3000A/L, XC3100A/L 

Settings: Before. After 

Default: After 
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-g (Set Configuration—XC4000 and Spartan) 

Note: For Spartan2 -g options, see the "-g (Set Configuration—Virtex 
and Spartan2 Devices)" section. 

Tills option specifies the startup timing and other bitstream options 
for the XC4000E/L. XC4000EX/XL/XV' and Spartan devices. Timing 
sequences are predefined startup defaults that use the following 
syntax. 

bitgen -g tinting_sa{umce 

Tliere are four valid startup sequences: Cclk Nosync, Cclk Sync, 
Uclk Nosync, and Uclk Sync. These startup sequences are described 
in the next section. For more information about startup timing, refer 
to The Programmable Logic Data Bonir. 

Tine default startup sequence for the -g option is Cclk Nosync. This 
startup sequence makes an XC-KXX) or Spartan device compatible 
with an XC3XOO device that is set for early Done and late Reset. Enter 
the following, 

bitgen -g cclk nosync 

Tine -g option has sub-options that represent settings you use to set 
the configuration for an XC-KXX) or Spartan design. Unese options 
have the following syntax. 

bitgen -g option : idling 

For example, to enable Cyclic Redundancy Checking (CRC), use the 
following syntax. 

bitgen -g crc:enable 

Tine following sections describe the startup sequences for the -g 
option. 

Startup Sequences and the -g Option 

This section describes the four predefined startup sequences and 
their defaults; then it describes the options, their settings, and their 
defaults. 

Note: When mixing devices, the one with the latest "finished point" 
should be the master. The master stops clocking when it readies the 
finished point. See The Programmable Logic Data Book for more 
information. 
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Cclk_Nosync 


Tills is the default startup sequence for the -g option. Selecting this 
sequence causes the following defaults to take effect. 

StartupClk: 

Cclk 

SyncToDone: 

Ho 

DoneActive: 

Cl 

OutputsActive: 

C2 

GSRlnactive: 

C3 

This startup sequence makes an XC4000, Spartan, or XC520I1 device 
consistent with an XC3XOO device set for early Done and Lite Reset. 

Cclk_Sync 


Selecting this sequence causes the following defaults to take effect. 

StartupClk: 

Cclk 

SyncToDone: 

Yes 

DoneActive: 

Cl 

OutputsActive: 

DI PLUS _1 

GSRlnactive: 

DI PLUS 1 


This startup sequence is the most consistent with the XC3XOO devices, 
since it synchronizes the release of GSR and 1/Os to the external 
Doneln signal. This startup sequence makes an XC4000 or Spartan 
device consistent with an XC3XOO device set for early Done and late 
Reset. 

Uclk_Nosync 

Selecting this sequence causes the following defaults to take effect. 
StartupClk: Userclk 

SyncToDone: No 

DoneActive: U2 

OutpuLsActive: 03 

GSRlnactive: U4 
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Tills startup sequence makes XC4000 or Spartan devices inconsistent 
with XC3XOO devices if they are in tlie same daisy chain, since the 
release of Done is synchronized to an external User Clock. There is no 
synchronization of I/Os or GSR to Doneln. 


Uclk_Sync 

Selecting this sequence causes the following defaults to take effect. 


StartupClk: 

SyncToDone: 

DoneActive: 

OutputsActive: 

GSRlnactive: 


Userclk 

Yes 

U2 

DI PLUS 1 
DI PLUS 2 


This startup sequence makes XC4000 or Spartan devices inconsistent 
with XC3X00 devices if they are in the same daisy chain, since the 
release of Done is synchronized to an external User Clock. I/Os and 
GSR are synchronous to the clocks following Doneln. 

When using Uclk Sync or Uclk Nosync, you must provide a user 
clock to finish the configuration sequence. Without a user clock the 
FPGA will not configure. 


Sub-Options tor Startup Sequence (-g Option) 

The sub-options available with the four startup sequences are 
described below. These sub-options use the -g option: setting syntax. 


AddressLines 

Determines the number of address lines (IS or 22) used for device 
configuration. The 22 setting activates four extra device pins as 
configuration address lines. 

Architectures: XC4000EX only (XC4(X)0XL, XC4000XLA, and 

XC4000XV always have 22 active address lines) 
Settings: 18.22 

Default: 18 
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BSCANConlig 

When disabled, BSCAN Config inhibits the BSCAN-based 
configuration after the device is successfully configured. This feature 
allows board testing without the risk of reconfiguring XLA devices 
by toggling the TCK/TMS/TDI/TDO lines. 

Architectures: XC4000XLA. XC4000XV. SpartanXL 

Settings: Disable. Enable 

Default: Enable 

BSCANStatus 

When enabled, BSC AN Status allows direct sensing of the DONE 
configuration state after performing a BSCAN-based configuration. 
Previously, there was no direct method for determining if a BSCAN- 
based configuration was successful. 

Architectures: XC4000XLA. XC4000XV. SpartanXL 

Settings: Disable. Enable 

Default: Disable 

5V_Tolerant 

If set to On, this option allows a 3.3V device circuitry to tolerate 5V 
operation. For any device that operates on a mixed circuit 
environment with 3.3V and 5V, ensure that On is set. For any 
circuitry that operates exclusively on 3.3V, such as in a laptop 
computer, set the option to Off. The Off option reduces power 
consumption. 

Architectures: XC4000XLA. XC4000XV. SpartanXL 

Settings: On, Off 

Default: On 


Development System Reference Guiite 


16-13 




Development System Reference Guide 


ConfigRale 

Selects the configuration clock rate. There are two choices: slow or 
fast. Slow is equivalent to 1 MHz, and fast is equivalent to 8 MHz 
(nominal). 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV, Spartan, 

and SpartanXL 
Settings: Slow. Fast 

Default: Slow 

CRC 

Enables or disables Cyclic Redundancy Checking (CRC) on a chip- 
by-chip basis during configuration. 

Architectures: XC4000E/L, XC4000EX/XL/XL.A/XV, Spartan, 

and SpartanXL 

Settings: Enable. Disable 

Default: Enable 

Done Active 

Selects the event that activates the FPGA Done signal. There are a 
maximum of four events that you can select from at one time. These 
events are Cclk edges or external (user) clock edges. 
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Tine actual options available at any time depend on the selections 
made for StaitupClk and SyncToDone. 

XC4000E/L, XC4000EX/XL/XV/XLA, Spartan, 
and SpartanXL 

Cl — first-Cclk rising edge after the length 
count is met. 

C2 — second-Cclk rising edge after the length 
count is met. 

C3 — third-Cclk rising edge after the length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U 2 — second-valid-user-clock rising edge after 
Cl. 

03 — third-valid-user-dock rising edge after Cl. 
U4 — fourth-valid-user-clock rising edge after 
Cl. 

Default: Cl 


Valid settings for DoneActive are as follows. 


StartupCIk 

SyncToDone 

DoneActive 

Cclk 

Yes 

Cl, C2 or C3 

Cclk 

No 

Cl, C2, C3, or C4 

UserClk 

Yes 

Cl or U2 

UserClk 

No 

Cl.U2.U3, or U4 


DonePin 

Enables or disables internal pull-up on the DONE pin. The Pullnone 
setting indicates there is no connection to the pull-up. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV. Spartan, 

and SpartanXL 

Settings: Pullup. Pullnone 

Default: Pullup 


Architectures: 

Settings: 
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ExpressMode 

When enabled, ExpressMode creates a unique type ot bitstream tor 
configuration. 

Architectures: XC4000XLA. XC4000XV 

Settings: Disable. Enable 

Default: Disable 

GSRInactive 

Selects the event that releases the internal set-reset to the latches and 
flip-flops. You can select one of nine events: a Cclk edge, an external 
(user) clock edge, or the external signal Doneln. Only some of these 
events become options at one time depending on the combination of 
StartupClk and SyncToDone selected. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV. Spartan, 

SpartanXL 

Settings: C2 — second-Cclk rising edge after the length 

count is met. 

C3 — third-Cclk rising edge after the length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U 2 — second-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

U3 — third-valid-user-clock rising edge after C1 
(first-Cclk rising edge after length count is met). 
04 — fourth-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

DI — when the Doneln signal goes High. 

DI PLUS 1 — first Cclk or valid user clock 
rising edge (depending on selection ot 
StartupClk) after Doneln goes High. 

DI PLUS 2 — second Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High. 

Default: C3 
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Valid ‘tellings for GSRInactive are as follows. 


StartupCIk 

SyncToDone 

GSRInactive 

Cclk 

Yes 

C2, C3, Dl, or Dl PLUS 1 

Cclk 

No 

C2. C3, or C4 

UserClk 

Yes 

U2,DI, DI PLUS 1, or Dl PLUS 2 

UseiClk 

No 

U2, U3, or U4 


Input 

SeLs the inpul threshold level for IOBs. 

Architectures: XC4000E/L, XC400DEX. Spartan 

Sellings: TTL. CMOS 

Default: TTL 

LC_Alignment 

Tine LC Alignment option determines how length count is calculated 
to control when the device changes from configuration to user 
operation. The two methods of calculating length count, DONE 
Alignment and Length Count Alignment, are discussed in the 
Configuration section of the The Programmable Logic Dalii Book. The 
FPGA Configuration Guidelines Application Note also contains length 
count infoimation. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV Spartan, 

SparlanXL 

Settings: Length. DONE 

Default: Length 
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MOPin 

Adds a pull-up or a pull-down lo the MO (Mode 0) pin. Selecting one 
option enables it and disables the others. The Pullnone setting 
indicates there is no connection to either the pull-up or the pull¬ 
down. 

Architectures: 

Settings: 

Default: 

Ml Pin 

Adds a pull-up or a pull-down lo the Ml (Mode 1) pin. Selecting one 
option enables it and disables the others. The Pullnone setting 
indicates there is no connection to either the pull-up or the pull¬ 
down. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullnone 

M2Pin 

Adds a pull-up or a pull-down to the M2 (Mode 2) pin. Selecting one 
option enables it and disables the others. The Pullnone setting 
indicates there is no connection to either the pull-up or the pull¬ 
down. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullnone 

Output 

Sets the output level for lOBs. 

Architectures: XC4000E/L, XC4000EX, Spartan 

Settings: TTL. CMOS 

Default: TTL 


XC4000E/L, XC4000EX /XL/XL A / XV, Spar- 
tanXL 

Pullup.Pulldown.Pullnone 
Pullnone 
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OutputsActive 

Selects Ihe event that releases the I/O from 3-slate condition and 
turns the configuration related pins operational. There are a 
maximum of four events that you can select from at one time. These 
events are selected from a group of Cclk edges, a group of external 
(user) clock edges, and the external signal Done In. The actual options 
available at any time depend on the selections made for StartupClk 
and SyncToDone. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV, Spartan, 

SparlanXL 

Settings: C2 — second-Cclk rising edge after the length 

count is met. 

C3 — third-Cclk rising edge after Ihe length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U2 — second-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

U3 — third-valid-user-clock rising edge after Cl 
(first-Cclk rising edge after length count is met). 
U4 — fourth-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

DI — when Ihe Doneln signal goes High 
DI PLUS 1 — first Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High 
DI PLUS 2 — second Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High 
Default: C2 


Deivloptneil System Reference Guide 


16-19 




Development System Reference Guide 


Valid sellings for OutputsAclive are as follows. 


StartupCIk 

SyncToDone 

OutputsAclive 

Cclk 

Yes 

C2.C3, Dl.orDI PLUS ! 

Cclk 

No 

C2. C3, or C4 

UserClk 

Yes 

U2.DI.DI PLUS. 1, or D1 PLUS 2 

UseiClk 

No 

U2, U3, or U4 


PowerDown 

Enables or disables internal pull-up on Ihe PowerDown pin. The 
Pullnone selling indicates there is no connection to Ihe pull-up. 

Architectures: SparlanXL 

Sellings: Pullup, Pullnone 

Default: Pullup 

ReadAbort 

Enables or disables aborting Ihe readback sequence during Ihe 
rcadback sequence. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV. Sparlan, 

SparUnXL 

Sellings: Enable. Disable 

Default: Disable 

ReadCaplure 

Enables or disables rcadback of configuration bitstream. 

Architectures: XC4000E/L. XC4000EX/XL/XLA/XV, Sparlan. 

SparUnXL 

Sellings: Enable. Disable 

Default: Disable 
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ReadClk 

Sets the readback clock to be CClk or to a user-supplied clock (from a 
net inside the FPGA that Ls connected to the 'i' pin of the RDCLK 
schematic block). 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV, Spartan, 

SparUnXL 

Settings: Cclk (pin—see Note), Rdbk (user-supplied) 

Default: Cclk 

Note: In modes where CClk is an output, the pin is driven by the 
internal oscillator. 

StartupCIk 

Selects a user-supplied clock or the internal Cclk for controlling the 
post-configuration startup phase of the FPGA initialization. 

Architectures: XC4000E/L. XC4000EX/XL/XLA/XV, Spartan, 

SparUnXL 

Settings: Cclk (pin—see Note), UserClk (user-supplied) 

Default: Cclk 

Note: In modes where Cclk is an output, the pin is driven by the 
internal oscillator. 

SyncToDone 

Synchronizes the I/O startup sequence to the external Done In signal. 

Architectures: XC4000E/L, XC4000EX/XL/XLA/XV. Spartan, 

SparUnXL 

Settings: Yes. No 

Default: No 
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TdoPin 

Adds a pull-up, a pull-down, or neither to the TDO pin (Test Data 
Out for Boundary Scan). Selecting one option enables it and disables 
the others. The Pullnone setting indicates there is no connection to 
either the pull-up or the pull-down. 

Architectures: XC4G00E/L, XC4000EX/XL/XLA/XV, Spartan, 

SparlanXL 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullnone 

-g (Set Configuration—XC5200 Devices) 

The -g option has sub-options that represent settings you use to set 
the configuration for an XC52(X) design. These options have the 
following syntax. 

bitgcn -g option:setting 

For example, to enable Cyclic Redundancy Checking (CRC), use the 
following syntax. 

bitgen -g crc:enable 

Tile following sections describe the startup sequences for the -g 
option. 

BSReconfig 

Enable or disable reconfiguration via boundary scan. 

Architectures: XC5200 

Settings: Disable. Enable 

Default: Disable 

BSReadback 

Enable or disable reading back configuration data via boundary scan. 
Architectures: XC5200 

Settings: Disable. Enable 

Default: Disable 
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ConfigRate 

Selects Ihe configuration clock rate. There are three choices: slow, 
med, and fast. Slow is equivalent to .75 MHz. med is equivalent to 6 
MHz, and fast is equivalent to 12 MHz (nominal). 

Architectures: XC5200 

Settings: Slow. Med. Fast 

Default: Slow 

CRC 

Enables or disables Cyclic Redundancy Checking (CRC) on a chip- 
by-chip basis during configuration. 

Architectures: XC5200 

Settings: Enable. Disable 

Default: Enable 

Input 

This option sets the FPGA design input-signal thresholds to TTL or 
CMOS level for interface capability. CMOS improves noise immunity 
and reduces static power consumption. 

Tire special-purpose clock inputs,TCLK1N, BCLKIN, and I’WRDM 
always require CMOS-level signals, even if the FPGA design input 
thresholds are specified as TTL compatible. 

Architectures: XC5200 

Settings: TTL. CMOS 

Default: TTL 

Done Active 

Selects the event that activates the FPGA Done signal. There are a 
maximum of four events that you can select from at one time. These 
events an? Cclk edges or external (user) clock edges. 
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Tine actual options available at any time depend on the selections 
made for StaitupClk and SyncToDone. 

Architectures: XC5200 

Settings: Cl — first-Cclk rising edge after the length 

count is met. 

C2 — second-Cclk rising edge after the length 
count is met. 

C3 — third-Cclk rising edge after the length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U 2 — second-valid-user-clock rising edge after 
Cl. 

U3 — third-valid-user-clock rising edge after Cl. 
U4 — fourth-valid-user-clock rising edge after 
Cl. 

Default: Cl 


Valid settings for Done.Active are as follows. 


StartupCIk 

SyncToDone 

Done Active 

Cclk 

Yes 

Cl, C2 or C3 

Cclk 

No 

Cl, C2, C3, or C4 

UserClk 

Yes 

Cl or U2 

UseiClk 

No 

C1.U2.U3, or U4 


DonePin 

Enables or disables internal pull-up on the DONE pin. The Pullnone 
setting indicates there is no connection to the pull-up. 


Architectures: XC5200 

Settings: Pullup.Pullnone 

Default: Pullup 
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GSRInaclive 

Selects the event that releases the internal set-reset to the latches and 
flip-flops. You can select one of nine events: a Cclk edge, an external 
(user) clock edge, or the external signal Doneln. 

Only some of these events become options at one time depending on 
the combination of StartupClk and SyncToDone selected. 

Architectures: XC5200 

Settings: C2 — second-Cclk rising edge after the length 

count is met. 

C3 — thiid-Cdk rising edge after the length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U2 — second-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

03 — third-valid-user-clock rising edge after Cl 
(first-Cclk rising edge after length count is met). 
U4 — fourth-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

DI — when the Doneln signal goes High 
DI PLUS 1 — first Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High 
DI PLUS 2 — second Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High 
Default: C3 


Valid settings for GSRInactive are as follows. 


StartupClk 

SyncToDone 

GSRInactive 

Cclk 

Yes 

C2. C3, DI. or DI PLUS .l 

Cclk 

No 

C2. C3, or C-l 

UserClk 

Yes 

U2, DI, DI PLUS 1, or DI PLUS 2 

UserClk 

No 

U2, U3, or U-l 
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Input 

Sets the input threshold level for IOBs. 

Architectures: XC5200 

Settings: TTL. CMOS 

Default: TTL 

LC_Alignment 

Tine LC Alignment option determines how length count is calculated 
to control when the device changes from configuration to user 
operation. The two methods of calculating length count, DONE 
Alignment and Length Count Alignment, are discussed in the 
Configuration section of The Programmable Logic Ditto Book. The FPGA 
Configuration Guidelines Application Note also contains length count 
information. 

Architectures: XC52CK1 

Settings: Length. DONE 

Default: Length 

OscClk 

Determines whether the XC5200 oscillator is driven by the internal 
16-MHz clock (CClk setting) or by a user clock (UserClk setting). If 
you specify UseiClk. the clock must be connected to the OSC.CK pin 
of the device's OSC component. 

Architectures: XC5200 

Settings: UserClk. CClk 

Default: Cclk 

OutputsActive 

Selects the event that releases the I/O from 3-state condition and 
turns the configuration related pins operational. There are a 
maximum of four events that you can select from at one time. These 
events are selected from a group of Cclk edges, a group of external 
(user) clock edges, and the external signal Doneln. 
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Tine actual options available at any time depend on the selections 
made for StaitupClk and SyncToDone. 

Architectures: XC5200 

Settings: C2 — second-Cclk rising edge after the length 

count is met. 

C3 — third-Cclk rising edge after the length 
count is met. 

C4 — fourth-Cclk rising edge after the length 
count is met. 

U2 — second-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

03 — third-valid-user-clock rising edge after C1 
(first-Cclk rising edge after length count is met). 
U4 — fourth-valid-user-clock rising edge after 
Cl (first-Cclk rising edge after length count is 
met). 

DI — when the Doneln signal goes High 
DI PLUS 1 — first Cclk or valid user clock 
rising edge (depending on selection of Star- 
tupCIk) after Doneln goes High 
DI PLUS 2 — second Cclk or valid user clock 
rising edge (depending on selection of 
StartupClk) after Doneln goes High 
Default: C2 


Valid settings for OutputsActive are as follows. 


StartupClk 

SyncToDone 

OutputsActive 

Cclk 

Yes 

C2, C3, DI, or DI PLUS ! 

Cclk 

No 

C2, C3, or C-l 

UserClk 

Yes 

U2, DI, DI PLUS. 1, or DI PLUS 2 

UserClk 

No 

U2, U3, or U4 
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ProgPin 

Enables or disables internal pull-up on the I'KlIiiRAM pin. The pull- 
up affects the pin after configuration. The Pullnone setting indicates 
there is no connection to the pull-up. 

Architectures: XC5200 

Settings: Pullup. Pullnone 

Default: Pullup 

ReadAbort 

Enables or disables aborting the readback sequence during the 
rcadback sequence. 

Architectures: XC52CK1 

Settings: Enable. Disable 

Default: Disable 

ReadCapture 

Enables or disables rcadback of configuration bitstream. 
Architectures: XC5200 

Settings: Enable. Disable 

Default: Disable 

ReadClk 

Sets the rcadback clock to be CClk or to a user-supplied clock (from a 
net inside the FPGA that Ls connected to the V pin of the RDCLK 
schematic block). 

Architectures: XC5200 

Settings: Cclk (pin—see Note), Rdbk (user-supplied) 

Default: Cclk 

Note: In modes where CClk is an output, the pin is driven by the 
internal oscillator. 
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SlartupCIk 

Selects a user-supplied clock or the internal Cclk for controlling the 
post-configuration startup phase of the FPGA initialization. 

Architectures: XC5200 

Settings: Cclk (pin—see Note), UserClk (user-supplied) 

Default: Cclk 

Note: In modes where Cclk is an output, the pin is driven by the 
internal oscillator. 

SyncToDone 

Synchronizes the I/O startup sequence to the external Doneln signal. 
Architectures: XC5200 

Settings: Yes. Ho 

Default: No 

-g (Set Configuration—Virtex and Spartan2 Devices) 

The -g option has sub-options that represent settings you use to set 
the configuration for a Virtex or Spartan2 design. These options have 
the following syntax. 

bitgen -g option: selling 

For example, to enable Readback. use the following syntax. 

bitgen -g Readback 

The following sections describe the startup sequences for the -g 
option. 

ReadBack 

This option allows you to perform Readback by the creating the 
necessary bitstream. 
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ConfigRate 

Virtex and Spartan2 use an internal oscillator to generate the 
configuration clock. CCI.K, when configuring in a master mode. Use 
the configuration rate option to select the rate for this clock. 

Architectures: Virtex, Spartan2 

Settings: To find out settings, enter bitgcn -h virtex. 

Values are in MHz. The default is 4. 

Default: The default is the firs* item ILsted with bitgen - 

h virtex command. 

GcIkdelO. Gclkdell. Gclkdel2. Gclkdel3 

Use these options to add delays to the global clocks. You should not 
use this option unless instructed by Xilinx. 

Architectures: Virtex. Spartan2 

Settings: 11111, binary string 

Default: 11111 

StartupCIk 

Tine startup sequence following the configuration of a device can be 
synchronized to either Cclk. a User Clock, or the JTAG Clock. The 
default is Cclk. 

• Cclk 

Enter Cclk to synchronize to an internal clock provided in the 
FPCA device. 

• UserClk 

Enter UseiClk to synchronize to a user-defined signal connected 
to the CLK pin of the STARTUP symbol. 
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• Jtag Clock 

Enter JtagClk to synchronize to the clock provided by JTAG. This 
dock sequences the TAP controller which provides the control 
logic lor JTAG. 

Architectures: Virtex, Spartan2 

Settings: Cclk (pin—see Note), UserClk (user-supplied), 

JtagCLK 

Default: Cclk 

Note: In modes when* Cclk is an output, the pin is driven by an 
internal oscillator. 

PowerupCIk 

Selects which clock to synchronize to at the end of power up. 
Architectures: Spartan2 only 

Settings: IntOac, UserClk, CClk 

Default: IntOsc 

CclkPin 

Adds an internal pull-up to the Cclk pin. The Pullnone setting 
disables the pullup. 

Architectures: Virtex, Spartan2 

Settings: Pullnone, Pullup 

Default: Pullup 

DonePin 

Adds an internal pull-up to the DonePin pin. The Pullnone setting 
disables the pullup. 

Use this option only if you are planning to connect an external pull- 
up resistor to this pin. The internal pull-up resistor is automatically 
connected if you do not use this option. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pullnone 

Default: Pullup 
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DrivePDStatusPin 

Enables this output power-down status pin. 

Architectures: Spartan2 only 

Settings: Yes, No 

Default: Yes 

MOPin 

Tine MO pin is used to determine the configuration mode. Adds an 
internal pull-up, pull-down or neither to the MO pin. The following 
settings are available. The default Ls PullUp. Select Pullnone to 
disable both the pull-up resistor and pull-down resistor on the MO 
pin. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullup 

Ml Pin 

Tine Ml pin is used to determine the configuration mode. Adds an 
internal pull-up, pull-down or neither to the Ml pin. The following 
settings are available. The default is PullUp. 

Select Pullnone to disable both the pull-up resistor and pull-down 
resistor on the Ml pin. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullup 
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M2Pin 

The M2 pin is used to determine the configuration mode. Adds an 
internal pull-up. pull-down or neither to the M2 pin. The default is 
PullUp. Select Pullnone to disable both the pull-up resistor and 
pull-down resistor on the M2 pin. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullup 

PDStatusPin 

Adds an internal pull-up to the PDStatusPin pin. The Pullnone 
setting disables the pullup. 

Use this option only if you am planning to connect an external pull- 
up resistor to this pin. 

Architectures: Spartan2 only 

Settings: Pullup. Pullnone 

Default: Pullnone 

PowerdownPin 

Adds an internal pull-up to the input PowerdownPin pin. Tire 
Pullnone setting disables the pullup. 

Use this option only if you am planning to connect an external pull- 
up resistor to this pin. 

Architectures: Spartan2 only 

Settings: Pullup. Pullnone 

Default: Pullnone 

ProgPin 

Adds an internal pull-up to the ProgPin pin. Tire Pullnone setting 
disables the pullup. The pull-up affects the pin after configuration. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pullnone 

Default: Pullup 
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TckPin 

Adds a pull-up. a pull-down or neither to the TCK pin. the JTAG test 
clock. Selecting one setting enables it and disables the others. The 
Pullnone setting indicates then? is no connection to either the pull-up 
or the pull-down. 

Architectures: 

Settings: 

Default: 

TdiPin 

Adds a pull-up, a pull-down, or neither to the TD1 pin. the serial data 
input to all [TAG instructions and JTAG registers. Selecting one 
setting enables it and disables the others. The Pullnone setting 
indicates there is no connection to either the pull-up or the pull¬ 
down. 

Architectures: 

Settings: 

Default: 

TdoPin 

Adds a pull-up. a pull-down, or neither to the TdoPin pin. the serial 
data output for all JTAG instruction and data registers. Selecting one 
setting enables it and disables the others. The Pullnone setting 
indicates there is no connection to either the pull-up or the pull¬ 
down. 

Architectures: Virtex, Spartan2 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullnone 


Virtex, Spartan2 

Pullup.Pulldown.Pullnone 
Pullup 


Virtex, Spartan2 

Pullup.Pulldown.Pullnone 
Pullup 
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TmsPin 

Adds a pull-up, pull-down, or neither to the TMS pin, the mode input 
signal to the TAP controller. The TAP controller provides the control 
logic tor (TAG. Selecting one setting enables it and disables the 
others. The Pullnone setting indicates there is no connection to either 
the pull-up or the pull-down. 

Architectures: Virtex,Spartan2 

Settings: Pullup. Pulldown. Pullnone 

Default: Pullup 

GSR_cycle 

Selects the Startup phase that releases the internal set-reset to the 
latches, flip-flops, and BRAM output latches. The Done setting 
releases GSR when the Doneln signal is High. Done In is either the 
value of the Done pin or a delayed version if Done Pi pe=Yes. 

Architectures: Virtex,Spartan2 

Settings: Done, 1, 2, 3, 4, 5, 6, Keep 

Default: 6 

Keep should only be used when partial reconfiguration is going to be 
implemented. Keep prevents the configuration state machine from 
asserting control signals that could cause the loss of data. 

GWE_cycle 

Selects the Startup phase that asserts the internal write enable to flip- 
flops, LUT RA.Ms, and shift registers. It also enables the BRAMs. 
Before the Startup phase both BRAM writing and reading are 
disabled.The Done setting asserts GVV’E when the Doneln signal is 
High. Doneln is either the value of the Done pin or a delayed version 
if DonePipe=Yes. The Keep setting is used to keep the current value 
of the GWE signal. 

Architectures: Virtex, Spartan2 

Settings: Done, 1, 2, 3, 4, 5, 6, Keep 

Default: 6 
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GTS_cycle 

Selects the Startup phase that ideases the internal tristate control to 
the lO buffers. The Done setting releases GTS when the Doneln signal 
is High. Doneln is either the value of the Done pin or a delayed 
version if DonePipe=Yes 

Architectures: Virtex, Spartan2 

Settings: Done. 1, 2, 3, 4, 5, 6, Keep 

Default: 5 

LCK_cycle 

Selects the Startup phase to wait until DLLs lock. If NoWait Ls 
selected, the Startup sequence does not wait for DLLs. 

Architectures: Virtex, Spartan2 

Settings: 0,1, 2, 3, 4. 5, 6, NoWait 

Default: NoWait 

DONE_cycle 

Selects the Startup phase that activates the FPGA Done signal. Done 
is delayed when DonePipe=Yes. 

Architectures: Virtex, Spartan2 

Settings: 1, 2, 3, 4. 5, 6 

Default: 4 

Persist 

Tills option is needed for Readback and Partial Reconfiguration using 
the configuration pins. It determines the data bus width and which 
IOBs are always in Configuration mode. These lOBs will be excluded 
from general use. The X8 setting must be selected to enable Readback. 

Architectures: Virtex, Spartan2 

Settings: No. XI, X8 

Default: No 
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Select XI for serial modes or X8 for SupeiS mode. The following table 
illustrates which pins are peisislent in serial and SuperS 
configurations. 


Serial Modes 

Super8 Mode 

CFG RDY 
(NTT) (I/O) 

CFG RDY 

(NTT) (I/O) 

TOUT (O) 

BUSY (O) 

DIN (I) 

DATA 0 (I/O) 


DATA 1 (I/O) 


DATA 2 (I/O) 


DATA 3 (I/O) 


DATA 4 (I/O) 


DATA 5 (I/O) 


DATA f> (I/O) 


DATA 7 (I/O) 


T3(!) 


RDWK(I) 


DriveDone 

Tills option actively drives CFG DONE (Done) high as opposed to 
using pullup. 

Architectures: Virtex, Sparlan2 

Settings: No. Yes 

Default: No 

DonePipe 

Tills option is intended for use with FPGAs being set up in a high¬ 
speed daisy chain configuration.When set to Yes. the FPGA waits on 
the CFG DONE (DONE) pin to go High and then waits for the first 
clock edge before moving to the Done state. 

Architectures: Virtex, Spartan2 

Settings: No. Yes 

Default: No 
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Security 

Selecting Level! disables Readback. Selecting Level2 disables 
Readback and Partial Reconfiguration. 

Architectures: Virtex, Spartan2 

Settings: None, level 1, Level2 

Default: None 

UserlD 

You can enter up to an 8-digit hexadecimal code in the User ID 
register. You can use the register to identify implementation 
revisions. 

-h or-help (Command Usage) 

-h architecture 

Displays a usage message for BitGen. The usage message displays all 
of the available options for BitGen operating on the specified 
architecture. 

-] (No BIT File) 

Do not create a bitstream file (.bit file). This option is generally used 
when you want to generate a report without producing a bitstream. 
For example, if you wanted to run DRC without producing a 
bitstream file, you would use the -j option. 

Note: The .msk or .rbt files may still be created. 

-I (Create a Logic Allocation File) 

Tills option creates an ASCII logic allocation file ( design. 11) for the 
selected design. The logic allocation file indicates the bitstream 
position of latches, flip-flops, and lOB inputs and outputs. 

In some applications, you may want to observe the contents of the 
FPGA internal registers at different times. The file created by the -1 
option helps you identify which bits in the current biLstream 
represent outputs of flip-flops and latches. Bits are referenced by 
frame and bit number within the frame. 
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Tine Hardware Debugger uses Hie design . 11 tile to locate signal 
values inside a readback bitstream. 

-m (Generate a Mask File) 

Creates a mask tile. This file is used to compare relevant bit locations 
tor executing a readback ot configuration data contained in an 
operating FPGA. 

-n (Save a Tied design) 

This command is used with the -t option (described below) to save 
the tied NCD file as file name.ncd (note the underscore in fiont of 
the file name). The tied design file is placed in the same directory as 
the output tile. It has the same root name as the output file with an 
.ncd extension. If you do not specify an output tile, the tied design file 
is placed in the input file's directory and is named file jmme.ncd, 
where file mine is the root name of the input file. Use TRACE to run 
timing analysis on the tied design. You can also use the FPGA Editor 
to check the effects ol the tiedown. This option is not supported for 
Virtex or Spartan2. 

-t (Tie Unused Interconnect) 

This option causes all unused interconnect to be tied to a logic low or 
to a known level, keeping internal noise and power consumption to a 
minimum. When you use the -t option. DRC runs first (before 
tiedown). BitGen terminates if any DRC error occurs. A DRC 
warning does not cause the bitstream generation program to abort, 
but it may cause tiedown to fail. 

Alter DRC, the -t option does the following. 

• Ties all possible unused interconnect to tie sites or unused CLB 
outputs and configures those outputs with a logic low (F=0 or 
G=0) 

• Attempts to tie any remaining intereonnect to CLB outputs which 
have not been designated as critical 

• Attempts to tie remaining interconnect to the global or to the 
auxiliary clock buffer outputs if unused (only in conjunction with 
the -a option) 
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Tlie only condition under which tie will add interconnect to a 
"critical" net is if you use the -u option (allowing interconnect to be 
added to critical nets as a "last resort"). A "critical" net is one with a 
priority greater than 3. 

Tine -t option does not add an XC4000 or XC5200 tristate buffer input 
(I) pin or tristate (T) pin to a net. 

When you add interconnect to used CLB or buffer outputs, delays 
may be added on any net to which the outputs arc connected. To 
prevent the added delay, assign the net a priority greater than 3. You 
can do this through the physical constraints file or through the FPGA 
Editor. See the PRIORITIZE physical constraint in the "Attributes, 
Constraints, and Carry Logic" chapter of the Libraries Guide. Note that 
flagging too many nets as critical could cause the tiedown to fail. 
When an interconnect is tied to a user-defined net. you get a message 
giving the number of nodes added to the net. Delay characteristics for 
the net associated with that source may change. (Only in conjunction 
with the -a option) 

When certain pins cannot be tied, you receive a warning message 
supplying information about the design’s untied interconnect. 

To remove the obstacles that have caused tiedown to fail, look 
carefully at nets close to an untied PIP. An input pin could have 
multiple input PIPs. and all of them could source the pin. If each of 
these PIPs is associated with a critical net, they are not used, and the 
input pin is left untied. To correct the problem, make one of the nets 
"non-critical." Do this by removing the PRIORITIZE constraint from 
the net in the PCF file or in the FPGA Editor. Then run TRACE (the 
timing analysis program) and evaluate any delay that might have 
been added to the net. (Only in conjunction with the -a option) 

If you use the -n option, the tied design is saved in a file 
. file mufif.ncd (note the underscore before the file name). You can 
load the file into the FPGA Editor and examine the results of tiedown. 
You can look at all of the original nets that have been affected by 
tiedown and the net delays before and after tiedown. 

Like unused internal interconnect, unused external I/O pins on the 
chip must also have defined signal levels, that is, they must not be in 
a floating condition. In XC4QG0E/EX FPGAs, unused lOBs arc 
automatically pulled HIGH with pull-up resistors. 
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Partial tiedown is the new default. Tiedown will print the number of 
untied nodes and then continue. See the -a option also. Partial 
tiedown i leivr ties to user signals. 

This option is not supported for Virtex or Spartan2. 

-u (Use Critical Nets Last) 

Because of possible added delay, tiedown does not add interconnect 
to any net that has been assigned a priority greater than 3. This option 
allows interconnect to be added to critical nets as a "last resort." 

Tills option is not supported for Virtex or Spartan2. 

-w (Overwrite Existing Output File) 

Enables you Co overwrite an existing BIT, LL, MSK, or RBT output 
file. 
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PROMGen 


Tliis program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC40HQOE/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

This chapter describes PROMGen. The chapter contains the 
following. 

• PROMGen" 

• "PROMGen Syntax" 


• "PROMGen Options" 

• "Examples" section 

PROMGen 

PROMGen formats a BilGen-generaled configuration bitstream (BIT) 
file into a PROM format file. The PROM file contains configuration 
data for the FPGA device. PROMGen converts a BIT file into one of 
three PROM formats: MCS-86 (Intel), EXORMAX (Motorola), or 
TEKHEX (Tektronix). It can also generate a Hex file format. 
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Figure 17-1 PROMGen 

There are two functionally equivalent versions of PROMGen. There is 
a stand-alone version you can access from an operating system 
prompt. There is also an interactive version, called tire PROM File 
Formatter, that you can access from inside the Design Manager for 
Alliance or the Project Manager in Foundation. This chapter lirst 
describes the stand-alone version, the interactive version is described 
in the PROM File Formatter Guide . 

You can also use PROMGen to concatenate bitstream files to daisy- 
chain FPGAs. 

Note: If the destination PROM Ls one of tlie Xilinx Senal PROMs, you 
are using a Xilinx PROM Programmer, and the FPGAs are not being 
daisy-chained, it is not necessary to make a PROM file. See the 
Hardware User Guide for more information about daisy-chained 
designs. 
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PROMGen Syntax 

To start PROMGen from file operating system prompt, use the 
following syntax. 

pcomgen [options] 

Options tan be any number of the options listed in the "PROMGen 
Options" section. Separate multiple options with spaces. 

PROMGen Files 

Tills section describes the PROMGen input and output files. 

Input Files 

The input to PROMGEN consists of BIT files— one or more bitstream 
files. BIT files contain configuration data for an FPGA design. 

Output Files 

Output from PROMGEN consists of the following files. 

• PROM files—The file or files containing the PROM configuration 
information. Depending on the PROM file format your PROM 
programmer uses, you can output a TEK, MCS, or EXO file. If 
you are using a microprocessor to configure your devices, you 
can output a HEX file, which contains a hexadecimal 
representation of the bitstream. 

• PRM file—The PRM file is a PROM image file. It contains a 
memory map of the output PROM file. The file has a .prm 
extension. 

Bit Swapping in PROM Files 

PROMGen produces a PROM file in which the bits within a byte are 
swapped compared to the bits in the input BIT file. Bit swapping 
(also called "bit miiroring") reverses the bits within each byte, as 
shown in the following figure. 
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Original Data 


Data in PROM File or HEX File 

X8074 

Figure 17-2 Bil Swapping 


8 A 

1000 1010 



0101 0001 

5 1 


In a bitstream contained in a BIT tile, the Least Significant Bit (LSB) Ls 
always on the left side of a byte. But when a PROM programmer or a 
microprocessor reads a data byte, it identifies the LSB on the right 
side of the byte. In order for the PROM programmer or 
microprocessor to read the bitstream correctly, the bits in each byte 
must first be swapped so they are read in the correct order. 

In this release of the Xilinx Development System, the bits are 
swapped for all of the PROM formats: MCS, EXO, and TEK. For a 
HEX file output, bit swapping is on by default, but it can be turned 
off by entering a -b PROMGen option that is available only for HEX 
file format. 
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PROMGen Options 

Tills section describes the options that are available for the 
PROMCen command. 

-b (Disable Bit Swapping—HEX Format Only) 

Tills option only applies if the -p option specifies a HEX file for 
the output of PROMGen. By default (no -b option), bits in the 
HEX file am swapped compared to bits in the input BIT files. If 
you enter a -b option, the bits are not swapped. Bit swapping is 
described in the "Bit Swapping in PROM Files" section. 

-d (Load Downward) 

procogen -d ItexaddressOfilename filename... 

Tills option loads one or more BIT files from the starting address in a 
downward direction. Specifying several files after this option causes 
the files to be concatenated in a daisy chain. You can specify multiple 
-d options to load files at different addresses. You must specify this 
option immediately before the input bitstream file. 

Here is the multiple file syntax. 

prorogen -d hexaddressO filename filename... 

Here is the multiple -d options syntax. 

procogen -d hexaddressl filename-d Iiexaddress2 filename... 

-1 (Execute Commands File) 

-f command .file 

The -f option executes the command line arguments in the specified 
command^file. For more information on the -f option, see the *'-f 
Option" section of the "Introduction" chapter. 

-help (Command Help) 

Tills option displays help that describes the PROMGen options. 
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-n (Add BIT Files) 

-n fileH. bit]/ff? 2 [. bit ]... 

Tills option loads one or more BIT tiles up or down from the next 
available address following the previous load. The first -n option 
must follow a -u or -d option because -n does not establish a 
direction. Files specified with this option are not daisy-chained to 
previous files. Files are loaded in the direction established by the 
nearest prior -u, -d, or -n option. 

The following syntax shows how to specify multiple files. When you 
specify multiple files, PROMGen daisy-chains the files. 

promgen -d hexitddress filed -n file! fle2... 

Tine syntax for using multiple -n options follows. Using this method 
prevents the files from being daisy-chained. 

promgen -d hexiiddress filed -n file I -n file!... 

-o (Output File Name) 

-o file 1 1 . exl]file 2 \. exf|._ 

Tills option specifies the output file name of a PRO.Vl if it is different 
from the default. If you do not specify an output file name, the PROM 
file has the same name as the first BIT file loaded. 

ext is the extension for the applicable PROM format. 

Multiple file names may be specified to split the information into 
multiple files. If only one name is supplied for split PROM files (by 
you or by default), the output PROM files are named fie tr.exl. where 
file is the base name. # is 0 , 1 , etc., and ext is the extension for the 
applicable PROM format. 

proogen -d hexoddiess filed -o filename 
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-p (PROM Format) 

-p lines I e*o I tek I hex! 

Tills option sots the PROM format to one of the following: MCS (Intel 
MCSS6), EXO (Motorola EXORMAX), TEK (Tektronix TEKHEX). The 
option may also produce a HEX file, which is a hexadecimal 
representation of the configuration bitstream used for 
microprocessor downloads. If specified, the -p option must precede 
any -u, -d, or -n options. The default format is MCS. 

-r (Load PROM File) 

-r promfile 

Tills option reads an existing PROM file as input instead of a BIT file. 
All of the PROMCen output options may be used, so the -r option 
can be used for splitting an existing PROM file into multiple PROM 
files or for converting an existing PROM file to another format. 

-s (PROM Size) 

-s promsizel promsizeZ.. 

Tills option sets the PROM size in kilobytes. The PROM size must be 
a power of 2. The default value is 64 kilobytes. The -s option must 
precede any -u, -d, or -n options. 

Multiple profitsize entries for the -s option indicates the PROM will be 
split into multiple PROM files. 

Note: PROMCen PROM sizes are specified in bytes. The 
Programmable Logic Data Book specifies PROM sizes in bits for Xilinx 
serial PROMs (see -x option). 

-u (Load Upward) 

-u IwxaddressOftteiunnel filename!... 

Tills option loads one or more BIT files from the starting address in 
an upward direction. When you specify several files after this option, 
PROMCen concatenates the files in a daisy chain. You can load files 
at different addresses by specifying multiple -u options. 

This option must be specified immediately before the input bitstream 
file. 


Development System Reference Guide 


1 7-7 




Development System Reference Guide 


-x (Specify Xilinx PROM) 

-x xilinx _prom I xilinx prom 2 ... 

The -x option specifies one or more Xilinx serial PROMs for which 
the PROM files are targeted. Use this option instead of the -s option if 
you know the Xilinx PROMs to use. 

Multiple xilinx prom entries for the -x option indicates the PRO.Vl 
will be split into multiple PRO.Vl files. 

Examples 

To load the file test.bit up from address 0x01100 in MCS format, enter 
the following information at the command line. 

promgen -u 0 test 

To daisy-chain the files testl.bil and testZbit up from address 0x0000 
and the files tesG.bit and tesH.bit from address 0x4000 while using a 
32K PROM and the Motorola EXORmax format, enter the following 
information at the command line. 

promgen -s 32 -p exo -u 00 testl test2 -u 4000 
test3 test4 

To load the file test.bit into the PROM programmer in a downward 
direction starting at address 0x400. using a Xilinx XC1718D PROM, 
enter the following information at the command line. 

promgen -x xcl718d -d 0x400 test 

To specify a PROM file name that is different from the default file 
name enter the following information at the command line. 

promgen options filename -o newfilename 
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NGDAnno 


This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• Spartan2 

• SpartanXL 

• Virtex 

This chapter describes the NGDAnno program. The chapter contains 
the following sections. 

• "Back-Annotation" 

• "NGDAnno" 

• " NGDAnno Syntax ” 

• "NGDAnno Files" 

• "NGDAnno Options" 

• "Dedicated Global Signals in Back-Annotation Simulation" 

• "Hierarchy Changes in Annotated Designs" 

• "Guaranteed Setup and Hold Check" 
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Back-Annotation 

In the back-annotation process, physical design information, 
including timing values, is distributed back to the logical design for 
back-end simulation. 

In the Xilinx Development System, back-annotation for FPGA 
designs operates as follows. 

• NGDAnno distributes delays, setup and hold times, and pulse 
widths in the physical NCD design file onto the logical design 
view represented in the NGD file. Physical component locations 
for PADs are also combined with the information in the NGD 
file. 

NGDAnno output is an NGA (Generic Annotated) file containing 
the logical design with annotations. 

• The annotated design NGA file is input to one of the netlist 
writers (NGD2EDIF, NGD2VER. or NGD2VHDL), which trans¬ 
lates the back-annotated information into netlist fomiat for simu¬ 
lation. 

In addition to back-annotating a fully routed design, the Xilinx 
Development System lets you back-annotate an unrouted design or 
create an output netlist to allow simulation of the design at different 
stages. For example, if you want to verify that the circuit logic is 
conect before you place and route your design with the Xilinx 
Development System tools, you can use the data in an unmapped 
NGD (Generic Description) design as input to the NGD2ED1F, 
NGD2VER, or NGD2VHDL program and run a simulation program 
on the resulting netlist. To simulate with components, and not route 
delays, you can run back-annotation on the unrouted NCD file from 
the MAP program. 

The back-annotation flow is shown in the following figure. 


IS-2 


Xilinx Deielo/'me/it System 




NGDAnno 



Figure 18-1 Back-Annotation 

You can run back-annotation by invoking NGDAnno and netlist 
leader programs from the UNIX or DOS command line or from the 
Design Manager/Flow Engine. Command line usage is explained in 
this chapter and in the netlist reader chapters. To use the [>»sign 
Manager/Flow Engine for any of the programs, see the Design 
Manager/Flow Engine Guide. 

NGDAnno 

NGDAnno distributes delays, setup and hold times, and pul.-*. 1 
widths in the physical NCD design file onto the logical design view 
represented in the NGD. 

NGDAnno merges mapping information from the NGM file and 
placement, routing, and timing information from the NCD file and 
puts this data in an NGA (Generic Annotated! file (see the "Back- 
Annotation" figure). 
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The NGA file is input to the appropriate translation program 
(NGD2F.DIF, NGD2VHDL, or NGDVER) used to convert the Xilinx 
format back to a netlist. 

Note: If you make logical changes to an NCD design in the FPGA 
Editor, and change the functional behavior of your design, 

NGDAnno cannot correlate the changed objects in the physical 
design with the objects in the logical design. It recreates the entire 
NGA design from the NCD file. You get a warning indicating that the 
NCD file is no longer synchronized with the NGM file, and that a 
new NGA file has been created from the NCD file. 

NGDAnno Syntax 

To perform back-annotation from the UNIX or DOS command line, 
enter the following. 

ngdanno [options] nedfile\.ncd\ |rt\*w_/i/i , [.ngm)| 

Ned. file is the input NCD (physical design file). If you specify an 
NCD file on the command line without specifying an NGM file, an 
NGA file is generated from the NCD only. The NGA file contains 
annotated information about the physical implementation, but there 
is no logical view of the design. If you specify both an NCD and an 
NGM file, the resulting NGA file contains both logical and physical 
information for the annotated design 

Ngin Jile is an optional NGM file—a mapped design file containing 
information about the physical design and information about how 
the physical design corresponds to the logical design. You must 
specify the NGM file for NGDAnno to use the file as input. In 
general, the NGM file should be used, especially with HDL synthesis- 
based designs. In the HDL design flow, the NGM file can help to 
regroup logic based on the original design hierarchy. 

If you do not specify an NGA file with the -o option (described in the 
"NGDAnno Options" section), an NGA file is generated in the same 
directory as the NCD. The NGA file has the same root name as the 
NCD file. 
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NGDAnno Files 

Tills section describes Ihe NGDAnno inpul and outpul files. 

Input Files 

Inpul lo Ihe NGDAnno program is Ihe following. 

• NCD file—Physical design file. The design may be mapped only, 
partially or fully placed, and partially or fully routed. 

• NGM file (optional but recommended)—Mapped NGD file 
created by the MAP program. 

• PCF file (optional)—Physical constraints file. 


Output Files 

Output from the NGDAnno program is the following. 

• NGA file—A back-annotated NGD file. 

• ALF file—An annotation report file containing information about 
the NGDAnno run. The ALF file has the same mot name as the 
output NGA file and an .alf extension. The file Ls written into the 
same directory* as the output NGA file. 

The following warning appears on your screen and in the ALF report 
file if a logical annotation failure, such as loss of correlation, occurs. 

WARNING:basna:22 - NGDANNO found physical copponents 
for which 100 percent back-annotation is not possible. 
{These components arc listed below.) Gone reasons 
these components may not be fully back-annotatablc 
include: 

1. The logic was replicated during physical rapping. 

2. MAP was directed to optimize the logic through use 
of the -oq or -os option, or the OPTIMIZE or 
OPT_EFFORT design attribute. 

3. The component's configuration inplics a more 
complex delay nodcl than can be accurately represented 
in the original design logic. An exanplc of such a 
configuration is an XC4000-family CLB containing both 
carry logic and nultiplc flip-flcps. 
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Simulation ncdels foe the following components will be 
constructed from the NCD netlist. Signal names buried 
within these components will be lost. 

When using minimum or prorated delays rather than standard 
delays (for example, when using the -s min option or when you have 
included prorating constraints in your PCF or UCF hie), one of the 
following warnings appears on your screen and in the ALF report 
file. 

WARNING - the delay calculations arc different from 
the standard delays. These are MINIMUM delays and 
therefore represent timing delays which may not 
accurately reflect the typical process delays. 

WASHING - the delay calculations arc different from 
the standard delays. These are PRORATED delays and 
therefore represent timing delays which may not 
accurately reflect the typical process delays.These 
delays were calculated at SOC and 3.3V. 

At the end of the operation, the following summary appears listing 
the number of annotated logical models, annotated physical models, 
and annotated physical macros. 

119 logical models annotated 
4 physical ncdcls annotated 
6 macros annotated 

In this case, the netlist writer looks at each physical block in the \’GA 
file. If its logical model was annotated, the logic model (including all 
user signals and primitives it contains) Ls used in the simulation 
netlist. If the physical model was annotated, the physical view of the 
block (containing Xilinx-generated signals and primitives) is used in 
the simulation netlist. 


18-6 


Xilinx Development System 




NGDAnno 


NGDAnno Options 

This section contains descriptions of NGDAnno command line 
options. 

-f (Execute Commands File) 

-£ command Jilt 

The -f option executes the command line arguments in the specified 
command, file. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-o (Output File Name) 

-o <ml_/T/e|. nga| 

The -o option specifies the output design file in NGA format. The 
.nga extension is optional. The output file name and its location are 
detemnined in this way. 

• If you do not specify an output file name with the -o option, the 
output file has the same name as the input NCD file, with an .nga 
extension. The file is placed in the input NCD file's directory. 

• If you specify an output file name with no path specifier (for 
example, cpu dec. nga instead of /home/designs/ 

cpu dec. nga). the NGA file is placed in the current working 
directory. 

• If you specify an output file name with a full path specifier (for 
example, /home/designs/cpu dec. nga), the output file is 
placed in the specified directory. 

If the output file already exists, it is overwritten with the new NGA 
file. 

-p (PCF File) 

-pj"/_yi/r.pc£ 

Tine -p option allows you to specify a PCF (Physical Constraints) file 
as input to NGDAnno. You only need to specify a constraints file if it 
contains the following. 
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• Level information (CMOS or TTL) for IOBs in a 4000E or 4000EX 
design 

• Prorating constraints 

Prorating constraints and prorated delays are described in the 
"Prorating Constraints" section of the "Using Timing Constraints" 
chapter. 

-s (Change Speed) 

-= 

Tire -s option instructs NGDAnno to annotate the device speed you 
specify to the NGA file. 

Tine device speed can be entered with or without the leading dash. For 
example, both -s 3 and -s -3 are allowable entries. 

Some architectures support the -s min option. This option instructs 
NGDAnno to annotate a minimum delay, rather than a maximum 
worst-case delay, to the NGA file. Tire command line syntax is the 
following. 

-s min 

-s -min is not an allowable entry. 

Note: Settings made with the -s min option override any prorated 
liming analysis. 

Dedicated Global Signals in Back-Annotation 
Simulation 

Tills section presents information on how global signals are treated in 
back-annotation simulation. 

Note: For a description of the STARTUP and STARTUP Y'lRTEX 
components, see the "Design Elements (SOP3 to XORCY L)" chapter 
of the Libraries Guide. 
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XC3000A/L and 3100A/L 

In XC3000 devices, the global reset signal (whose name varies 
depending on the CAE vendor) is assigned a pin on the device. You 
must include this pin in your call to the top level module and stimu¬ 
late the pin. The global reset signal should be pulsed low to reset all 
flip-flops in the design, then held high for normal operation. 

XC4000E/L, XC4000EX/XL/XV/XLA, and Spartan 

For XC4000 and Spartan devices, a high signal on the GSR (Global 
Set/Reset) net initializes each flip-flop and latch to the state (0 or 1) 
specified by its 1.MIT property (default is 0). A high signal on GTS 
(Global Tri-Stale) sets all outputs to a tristate condition. If you have 
not used the STARTUP component in your original design, these 
signals are initialized to their inactive states. Otherwise, you must 
stimulate the input GSR and GTS pins of the STARTUP device either 
directly or via logic from explicit pins on the device. 

XC5200 

In XC5200 devices, C.R (Global Reset) is assigned a pin on the device. 
You must include this pin in your call to the lop level module and 
stimulate the pin. Tire global reset signal is active-High. A high signal 
on GTS (Global Tri-State) sets all outputs to a tristate condition. If you 
have not used the STARTUP component in your original design, 
these signals are initialized to their inactive states. Otherwise, you 
must stimulate the input C.R and GTS pins of the STARTUP device 
either directly or via logic from explicit pins on the device. 


Virtex 

For Xilinx Virtex devices, a high signal on the GSR (Global Set/Reset) 
net initializes each flip-flop and latch to the state (0 or 1 ) specified by 
its IN'IT property (default is 0) and Block RAM data outputs to 0. LUT 
RAM, Block RAM content, DLL. and SRL are not affected by GSR. A 
high signal on GTS (Global Tri-State) sets all outputs to a tristate 
condition. If you have not used the STARTUP VIRTEX component in 
your original design, these signals are initialized to their inactive 
states. Otherwise, you must stimulate the input GSR and GTS pins of 
the STARTUP VIRTEX device either directly or via logic from 
explicit pins on the device. 
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Hierarchy Changes in Annotated Designs 

NGDAnno may flallen part of your original design hierarchy when 
generating a simulation netlist under the following conditions. 

• Logical correlation loss on a CLB due to logic optimization and 
logic replication during mapping 

• Logic mapped in this way is located in different parts of the 
design hierarchy 

For example, if a flip-flop with the hierarchical name A/B/X is 
merged with a flip-flop named A/C/Y, and the resulting CLB is 
affected by optimization or logic replication, hierarchical blocks A/B 
and A/C are flattened out of the netlist. The two flip-flops now lie at 
the same level of hierarchy (the A level) and are replaced by the CLB 
physical model. 

Tine netlist readers NGD2ED1F. NGD2VER, and NGD2VHDL 
generate a warning for each hierarchical block that is flattened. 

Guaranteed Setup and Hold Check 

In addition to the setup and hold checks already performed during 
back-annotation. NGDAnno creates a Guaranteed Setup and Hold 
Check (GSUH) primitive between each input pad that drives an lOB 
register and global clock pad that drives the register's clock pin. The 
GSUH values match closely with the pin-to-pin setup and hold 
values published in The Programmable Logic Ditto Book. Only device 
families and configurations that have published pin-to-pin setup and 
hold values are supported by the new GSUH primitive. 

This checking only occurs for lOBs and clock configurations that 
meet the requirements for a particular device. Generally, devices 
require an externally driven clock that uses the global clock resources 
to clock an input lOB register. Older device families may not support 
all GSUH combinations. 
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This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• Spartan2 

• SpartanXL 

• Virtex 

• XC9500 

• XC9500XL 

This chapter describes the NGD2EDIF program. The chapter contains 
the following sections. 

• "NGD2ED1F" 

• 'NGD2EDIF Syntax' 1 

• “NGD2ED1F Files" 

• "NGD2EDIF Options" 

• "XMM (RAM Initialization) File" 
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NGD2EDIF 

NGD2EDIF produces an EDIF 20 0 noil is I in terms of the Xilinx 

primitive set, allowing you to simulate pre- and post-route designs. 

NGD2EDIF can produce an EDIF file representing a design in any of 

these stages. 

• An unmapped design—To translate an unmapped design, the 
input to NGD2EDIF is an NGD file—a logical description of your 
design. The output from NGD2EDIF is an EDIF file containing a 
functional description of the design without timing information. 

• A mapped, unrouted design—To translate a mapped design that 
has not been placed and routed, the input to NGD2ED1F is an 
NGA file— an annotated logical description of your design— 
generated from a mapped physical design. The output from 
NGD2EDIF is an EDIF file containing a functional description of 
the design and timing information containing component delays 
but without routing delays. 

• A routed design—To translate a design which has been placed 
and routed, the input to NGD2EDIF is an NGA file generated 
from a routed physical design. The output from NGD2ED1F is an 
EDIF file containing a functional description of the design and 
timing information containing both component and routing 
delays. 

Tire design flow for NGD2EDIF is shown in the following figure. 
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Figure 19-1 NGD2EDIF Design Flow 


NGD2EDIF Syntax 

To invoke Ihe NC.D2EDIF translation program from the UNIX or 
DOS command line, enter the following. 

ngd 2 edif |e/>fw/is) infile[ .ngd I .nga) [oulfile\ .edn]] 

Options can be any number of the NCD2EDIF options listed in Ihe 
"NGD2EDIF Options" section. They do not need to be listed in any 
particular order. Separate multiple options with spaces. 

Infde\ . ngd I . nga| indicates the input file. If you enter a file name 
without an extension, NGD2ED1F looks for a file with an .nga 
extension and the name you specified. If you want to translate an 
NGD file, you must enter the .ngd extension. Without the .ngd 
extension NGD2EDIF does not use the NGD file as input, even if an 
NGA file is not present. 

Out/ilcl .edn] is the name of the NGD2ED1F output file if you want to 
name it other than the root NGD design name. If you do not give an 
extension, .edn is added. 

Note: If you are using the Vieivlogic design entry tools, the outfde 
name must be different from the original design name, to avoid 
conflict with the original WIR and ED1F files. See the "Timing 
Simulation" cliapter in the Vfewfo^rc Interface Guide for details. 
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NGD2EDIF Files 

Tills section describes the NGD2EDIF input and output tiles. 

Input Files 

Input to the NGD2EDIF program can be either of the following files. 

• NGA file—a Kick-annotated logical design file containing Xilinx 
primitive components 

• N'GD file—a logical design file containing Xilinx primitive 
components 

Output Files 

Output from NGD2EDIF consists of the following files. 

• EDN file—a netlist in ED1F format. The default EDN file 
produced by NGD2EDIF is generic. If you want to produce EDIF 
targeted to Mentor Graphics or View logic, you must include the 
-v option (described in the "-v (Vendor)" section) on the 
command line. 

• XMM file— an optional RAM initialization file, which defines the 
initial contents of the RAMs in the design for the simulator. The 
file is described in the "XMM (RAM Initialization) File" section. 

If an XMM file is generated, it lias the same base name and is 
written into the same directory as the output EDIF netlist. 

NGD2EDIF Options 

This section describes the NGD2EDIF command options. 

-a (Write All Properties) 

The -a option causes NGD2EDIF to write all properties into the 
output EDIF netlist. The default is to write only timing delay 
properties and certain other properties that define the behavior of the 
design logic (for example. RAM IN IT properties). In most cases the —a 
option is not necessary. Check with your simulation vendor on 
whether this option is a requirement for their tools. 


1 9-4 


Xilinx Development System 




NGD2EDIF 


-b (Use Buffers to Model Delays) 

Tlie -b option causes NGD2EDIF to model certain delays using 
buffers. The proper setting for the -b and -i options is chosen 
automatically if you entered a -v option. If your SimPrims library 
vendor is not one of the supported values for the -v option, consult 
the vendor for the proper -b and -i option settings. 

-c (Reference Design Name as Specified—Mentor) 

Tile -c option applies to the Mentor Graphics design flow. The option 
ensures that the output of Mentor's ENRead (EDIF reader) program 
is an EDDM Single Object simulation model registered to the design 
component located in the current directory. 

If the -c option is not specified, a library entry in the EDIF file 
instructs ENRead to place the simulation model in a subdirectory 
named design lib. For example, if your design name is added, 
ENRead places the simulation model in the subdirectory added lib/ 
added. 

If the -c option is specified, the library entry in the EDIF file instructs 
ENRead to place the simulation model directly in the design 
directory. For example, the simulation model for the design added is 
placed in the current directory right under added (as opposed to 
being placed in added lib/added). In this directory, the Mentor 
simulator finds the simulation model. 

If you specify the -c option, you must also specify both the -n 
(Generate Flattened Netlist) option and the -v (Vendor) option, with 
the -v option specifying -v mentor. 

-f (Execute Commands File) 

-f commandJile 

The -f option executes the command line arguments in the specified 
command Jilt\ For mom information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-I (Annotate Timing Properties to Instances) 

The -i option causes NGD2EDIF to annotate all timing properties to 
instances. The proper setting for the -i and -b options are chosen 
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automatically if you entered a -v option. If your SinnPrinns library 
vendor is not one of the supported values for the -v option, consult 
the vendor for the proper -i and -b option settings. 

-I (Local Scope) 

Tine -I option gives dedicated signals (such as the global SET/RESET 
signal) local (non-global) scope. If your simulation vendor is 
Foundation, Mentor Graphics, or Vieivlogic, the default NGD2EDIF 
action is to give dedicated signals global scope. If you are simulating 
a board-level schematic which references more than one Xilinx 
device, the global dedicated signals from each netlist are implicitly 
connected by the simulator. If this is not what you want, use the -1 
option to make the signals local to each device. You then need to 
reference each dedicated signal by the appropriate hierarelnically- 
qualified signal name. 

If your simulation vendor is not Foundation, Mentor Graphics, or 
Viewlogic, the -I option is enabled by default. 

-n (Generate Flattened Netlist) 

Tine -n option writes out a flattened netlist. 

-v (Vendor) 

-v vendor 

Tine -v option specifies the CAE vendor toolset that uses the resulting 
ED1F file. Allowable entries are vicwlog (for Viewlogic). mentor, 
and fndtn (for Foundation). 

Tine -v option customizes the output ED1F file for the specified 
vendor's simulator. The option also determines whether an XMM 
(RAM initialization) file is produced and the fomnat of the file (if one 
is produced). The XMM file is described in the next section. 

-vpt (Mentor Viewpoint) 

-vpt vieu'fioinl nante 

Tine -vpt option specifies the desired viewpoint for a Mentor ED1F 
output. 
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-w (Overwrite Output) 

Tine -w option specifies to overwrite the output lile. 

XMM (RAM Initialization) File 

Tine XMM file defines the initial contents of the RAMs in the design 
for the simulator. An XMM file is only created if the design contains 
RAMs. Some simulators require an XMM file; other simulators can 
lead the RAM initialization directly from the output ED1F file and do 
not need a separate XMM file. The way you use the file depends on 
the simulator vendor you specify with the -v option to NGD2ED1F. 

• If you are using a Viewlogic simulator (-v viewing), an XMM file 
is created in LOADM format for use by ViewSim. See the 
"Timing Simulation" chapter in the V7i‘ii'/i^ic Interface Guide lor 
information on loading the XMM file into ViewSim. 

• If you are using a Mentor Graphics simulator (-v mentor), no 
XMM file is created. QuickSim takes the RAM initialization 
information directly from the EDIF netlist. 

• If you are using another simulator (no -v option), an XMM file is 
generated in a generic format, which is described in the next 
section. Your simulator may or may not need this separate file; 
consult your vendor's documentation for details. 

Note: RAM initialization data is not created for the Virtex Block 
RAM. 

Generic File Format for XMM File 

Tills section describes the fomiat of the generic XMM file, which is 
created when the vendor (—v) option is not specified for NGD2ED1F. 
Consult you simulator vendor's documentation to determine how to 
use this generic XMM file. 

In most cases you do not need to understand the format of the generic 
XMM file. The following information is provided for reference. 
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For ease of processing by scripling languages. Ihe generic 
initialization file consists of newline-separated records. Each record 
has the following three tokens, separated by white space, with the 
position of each token denoting its meaning. 

primt!ve_type instancc_nanc inlt_valuc 

The tokens are defined as follows. 

Primitive type is the name of a RAM primitive in the Sim Prims 
library. It is a string value. 

Inslancejumie is a hierarchically-qualified instance name for a 
particular RAM SimPrim in the design. It is a string value. 
Hierarchical names are separated by the forward slash (/) character. 

Tine instance jtante is expressed in terms of the names in the original 
design, not in terms of the ED1F identifiers. The original names are 
more likely to correlate to the original design, but are not checked for 
uniqueness and may not be legal for the simulation interface. The 
simulation interface must read the generic initialization file to resolve 
these problems. 

Init value represents the contents of the specified RAM instance. Tire 
mil value is a hexadecimal number with a Ox prefix. The most 
significant bit of this number should be loaded into the highest 
address of the RAM. continuing so that the least-significant bit is 
loaded into the lowest address of the RAM As with the INIT 
property value, a one-bit-wide RAM is assumed. The number is 
padded with zeroes so that the number of bits exactly matches the 
number of addressable locations in the RAM primitive. 

Example: Generic Initialization File 

An example generic initialization file is shown following. 

X_RAHSl£ S1I32/$1I47/FIFO/BAHK03 0x£A«7 
X_RAH32 T0P/IFC/DATA/07 0 x003FQ97d 
X_RAKD l£ TOP/$3I107/S7l100 0x0000 

Tire generic initialization file also contains several comment lines that 
document when and how the file was made and describe the file 
format. Each comment line begins with a pound (#) character; these 
lines can be ignored by programs using the initialization file. 
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This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• Spartan2 

• SpartanXL 

• Virtex 

• XC9500 

• XC9500XL 

This chapter describes the NGD2VER program. The chapter contains 
the following sections. 

• "NCD2VER" 

• "NGD2VER Syntax" 

• "NGD2VER Files" 

• "NGD2VER Options" 

• "Setting Global Set/Reset. Tristate, and PRLD” 

• "Oscillator Functions (OSC, OSC4, OSC5J" 

• "NGD2VER Notes" 
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NGD2VER 

NGD2VER translates your design into a Verilog HDL file containing 
a nellist description of your design in terms of Xilinx simulation 
primitives. You can use the Verilog file to perform a back-end 
simulation with a Verilog simulator. 

Simulation is based on SimPrims. which create simulation models 
using basic simulation primitives. For example, a primitive for the 
XC4G00 dual-port RAM does not exist in the Verilog SimPrim library 
files. Instead, if a dual-port RAM is needed, NGD2VER builds a 
simulation model for the dual-port RAM out of two 16x1 RAM 
SimPrim primitives. 

NGD2VER can produce a Verilog file representing a design at any of 
the following stages. 

• An unmapped design—To translate an unmapped design, the 
input to NGD2VER is an NGD file—a logical description of your 
design. The output from NGD2VER is a Verilog file containing a 
functional description of the design without timing information. 

• A mapped, unrouted design—To translate a mapped design 
which has not been placed and routed, the input to NGD2VER is 
an NGA file— an annotated logical description of your design— 
generated from a mapped physical design. Tire output from 
N'GD2VF.R is a Verilog file containing a functional description of 
the design, and an additional SDF (Standard Delay Format) file 
containing timing information. Tire SDF file contains component 
delays without routing delays. 

• A routed design—To translate a design that has been placed and 
routed, the input to NGD2VER is an NGA file generated from a 
routed physical design. The output from NGD2VF.R is a Verilog 
file containing a functional description of the design and an SDF 
file containing both component and routing delays. 

Tire design flow for NGD2VER is shown in the following figure. 
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Figure 20-1 NGD2VER Design Flow 

NGD2VER Syntax 

Tine following command translates your design to a Verilog file. 

ngd 2 ver [i>/>ff<ws| infik[ . ngd nga| . v|| 

Options can be any number of the NGD2VER options listed in the 
"NGD2VER Options" section. They do not need to be listed in any 
pailicular order. Separate multiple options with spaces. 

Inftle |. ngd I . nga) is the input NGD or NGA file. If you enter a file 
name with no extension, NGD2VER looks for a file with an .nga 
extension and the name you specified. If you want to translate an 
NGD file, you must enter the .ngd extension. Without the .ngd 
extension NGD2VER does not use the NGD file as input, even if an 
NGA file is not present. 

Outfile\.v\ indicates the file to which the Verilog output of NGD2VER 
is written. Default is infile.v (infile is the same root name as the input 
file). The SDF file has the same root name as the Verilog file. 
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NGD2VER Files 

This section describes the NGD2VER input and output files. 

Input Files 

Input to NGD2VER can be either of the following files. 

• NGA—a back-annotated logical design file produced by 
NGDAnno. containing Xilinx primitives. 

• NGD—a logical design file produced by NGDBuild. containing 
Xilinx simulation primitives. 

Output Files 

Output from NGD2VER consists of the following files. 

• V file—a Verilog HDL file containing the netlist information 
obtained from the input NGD or NGA file. This file is a simula¬ 
tion model and cannot be synthesized or used in any other 
manner than simulation. This netlist uses simulation primitives 
which may not represent the true implementation of the device; 
however, the netlist represents a functional model of the imple¬ 
mented design. Do not modify this file. 

• SDF file—an SDF (Standard Delay Format) file containing delays 
obtained from the input file. NGD2VER only generates an SDF 
file if the input is an NGA file, which contains timing informa¬ 
tion. The SDF file generated by NGD2VER Ls based on SDF 
version 2 . 1 . 

Note: The SDF file should only be used with the Verilog file. Do not 

use the SDF file with the original design or with the product of 

another netlist writer. 

• LOG file—an optional log file created if you enter the -log option 
on the NGD2VER command line. It contains all the messages 
generated during the execution of NGD2VER. 

• TV file—an optional test fixture file created if you enter the -tf 
option on the NGD2VER command line. 

• PIN file—an optional Cadence signal-to-pin mapping file. 
NGD2VER generates a PIN file if the input file contains routed 
external pins and you have specified a -pf command line option. 
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NGD2VER only generates an PIN file if the input is an NGA file. 
The files have the same root name as the NGA file unless you 
specify otherwise. 

NGD2VER Options 

Tills section describes NGD2VER command options. 

-10ps (Set Time Precision to be lOps) 

Tine -lOps option changes the default timescale statement from 
'timescale Ins to ’ t imescale 1 Ops. This allows you to choose 
the appropriate simulation resolution based on your simulation run¬ 
time requirements. 

-aka (Write Also-Known-As Names as Comments) 

Tine -aka option includes user-defined identifiers as comments in the 
Yen log netlist. This option is used if user-defined identifiers are 
changed because of name legalization processes in NGD2VER. 

-cd (Include 'celldefineVendcelldefine in Verilog 
File) 

Tine -cd option applies to a Verilog file that will be used with the 
Cadence Synergy synthesis tool. The -cd option encloses every 
module definition in celldefine and 'endcelldefine constructs, as 
shown below. 

'cclldcflnc 

module <module_naire> 


cndmodulc 
'endedldefine 

The eelldefine and endcelldefine constructs tell the Cadence 
Synergy software to tieat an enclosed module as a black box (that is, 
do not try to synthesize the enclosed module). 

This option is used if a Cadence Synergy user instantiates a 
LogiBLOX module into the HDL source code. 
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-f (Execute Commands File) 

-f command, file 

The -f option executes the command line arguments in the specified 
command file . For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-gp (Bring Out Global Reset Net as Port) 

-gp portjtame 

The -gp option causes NGD2VER to bring out the global reset signal 
(which is connected to all flip-flops and latches in the physical 
design) as a port on the top-level module in the output Veiilog file. 
Specifying the port name allows you to match the port name you 
used in the front-end. Tine global reset signal is discussed in the 
"Dedicated Global Signals in Back-Annotation Simulation" section of 
the "NGDAnno" chapter. 

This option is only used if the global reset net is not driven. For 
example, if you include a STARTUP component in an XC4000 design, 
you do not have to enter a -gp option, because the STARTUP 
component drives the global reset net. 

Note: Do not use GR, GSR. PRELOAD, or RESET as port names, 
because these are reserved names in the Xilinx software. Also, do not 
use the name of any wire or port that already exists in the design, 
because this causes NGD2VER to issue a fatal error. 

-log (Specify the Log File) 

-log log Jilt’ 

Tine -log option generates a log file that contains all of the messages 
displayed during the execution of NGD2VER. Specify the name of 
the log file. By default, the name is ngd2ver.log. 

-ne (Replace Invalid Characters with Underscore) 

Tine -ne option overrides the default NGD2VER method of writing 
out identifiers that contain invalid characters. 

In a Verilog file, identifiers (names) must conform to the rules 
described in the "Verilog Identifier Naming Conventions" section. By 
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default (with no -ne option). NGD2VER writes identifiers that 
contain invalid characters with a leading backslash and a following 
white space. 

If you enter a -ne option, invalid characters are replaced with an 
underscore character (_), and the leading backslash does not appear 
as part of the identifier. The resulting Verilog file can be used if a 
vendor's Verilog software cannot interpret escaped identifiers 
correctly. 

-op (Specify the Period for Oscillator) 

-op oscillator_ptrwd 

Tine -op option specifies the period, in nanoseconds, for the oscillator. 
You must specify a positive integer to stimulate the component 
properly. If you do not enter a value for the -op option, the default is 

100 ns. 

-pf (Generate Pin File) 

Tine -pf option writes out a pin file—a Cadence signal-to-pin 
mapping file with a .pin extension. 

Note: NGD2VER only generates an PIN' file if the input is an NC.A 
file. 

-pms (Port Names Match Child Signal Names) 

Tine -pms option forces the port names and child signal names to 
match. 

-r (Retain Hierarchy) 

Tine -r option writes out a Verilog HDL file that retains the hierarchy 
in the original design as much as possible. Sonne loss of hierarchy 
may occur due to optimization. See the "Output Files" section of the 
"N'GDAnno" chapter for more information. If loss of hierarchy 
occurs, NGD2VER produces a warning for each level of user hier¬ 
archy that is lost. Following is an example. 

WARNING:NgdHclpcrs:182 - Hierarchical block 51174/ 

511126 has been flattened. The pins for this block 
Mill not be observable in the generated simulation 
model. 
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Tills option groups logic based on lhe original design hierarchy. To 
run NGD2VER with the -r option, you should have supplied an 
NGM file as input when you ran NGDAnno (see the "Input Files" 
section of the "NGDAnno" chapter). If you did not supply an NGM 
file, the NGA file produced is based on the NCD file, rather than the 
original design hierarchy. 

Tine default setting (with no -r option) produces a flattened Verilog 
HDL file. 

-sdf_path (Full Path to SDF File) 

-sdf path \pathjiame\ 

Tine -sdf option outputs the SDF file to the specified full path. This 
option writes the full path and the SDF file name to the Ssdf annotate 
statement. If a full path is not specified, it writes the full path of the 
current work directory and the SDF file name to the Ssdf annotate 
file. 

Note: NGD2VER only generates an SDF file if the input is an NGA 
file, which contains timing information. This option is allowed on an 
NGA file but not on an NGD file. 

-shm (Write $shm Statements in Test Fixture File) 

Tine -shm option places Sshm statements in the structural Verilog file 
created by NGD2VER. These Sshm statements allow VerilogXL to 
display simulation data as waveforms. 

-tf (Generate Test Fixture File) 

Tine -tf option generates a test fixtuiv file. The file has a .tv extension, 
and it is a ready-to-use template test fixture Verilog file based on the 
input NGD or NGA file. 

If you are using a Cadence Verilog simulator, you can run the 
simulator by entering verilog design.tv design . v, using the 
output V and TV files from NGD2VER You can then add more 
design-specific stimuli to this file to fit your needs. 
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-ti (Top Instance Name) 

-ti lopjnslance_name 

Tine -ti option specifies a user instance name for the design under test 
in the test fixture file created with the -tf option. 

-tm (Top Module Name) 

-tm topjnodulejumie 

Tine -tm option changes the name of the top-level module name 
appearing within the NGD2VER output files. If you do not enter a - 
tm option, the output files inherit the top module name from the 
input NGD or NGA file. 

-tp (Bring Out Global Trlstate Net as Port) 

-tp porljtame 

Tine -tp option causes NGD2VER to bring out the global tristate 
signal (which forces all FPGA outputs to the high-impedance stale) as 
a port on the top-level entity in the output Verilog file. Specifying the 
port name allows you to match the port name you used in the front- 
end. 

This option is only used if the global tristate net is not driven. For 
example, if you include a STARTUP component in an XC4000 design, 
you do not have to enter a -tp option, because the STARTUP 
component drives the global Instate net. 

Note: Do not use the name of any wire or port that already exists in 
the design, because this causes NGD2VER to issue a fatal error. 

-u (Use as Path Delimiter) 

Tine -u option produces an output Verilog file compatible with an 
AT&T Verilog simulator. This file contains an underbar (_) as a path 
delimiter, instead of the default forward slash (/) that is compatible 
with a Cadence Verilog simulator. 
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-ul (Write ‘uselib Directive) 

The -ul option causes NGD2VER to write a library path pointing to 
the SimPrim library into the output Verilog (.v) tile. Tire path is 
written as shown following. 

'uselib dir=3xiL!NX/veriiog/sre/siaprims libext-.v 

SXILISX is the location of the Xilinx software. 

This line is necessary for a Cadence Verilog simulator, but may 
confuse a simulator from another vendor. If you do not enter a -ul 
option, the 'uselib line is not written into the Verilog file. 

Note: A blank 'uselib statement is automatically appended to the end 
of the Verilog file to clear out the 'uselib data. 

-verbose (Display Processing Messages in Verbose 
Mode) 

The -vertrose option displays detailed Verilog processing messages 
during the execution of NGD2VER. 

-w (Overwrite Existing Files) 

The -w option causes NGD2VER to overwrite the output files if they 
already exist. Bv default (no -w specified) NGD2VER does not 
overwrite existing files. 

Setting Global Set/Reset, Tristate, and PRLD 

For information on setting Global Set/Reset for FPGAs, see the 
"Setting Verilog Global Set/Reset" section of the Synthesis and Simu¬ 
lation Design Guide. 

For information on setting Global Trislate for FPGAs, see the "Setting 
Verilog Global Tristate (XC4000, Spartan, and XC5200 Outputs 
Only)" section of the SyriUres/s and Simulation Design Guide. 

For information on setting Global PRLD for CPLDs, refer to the 
"Simulating Your Design" chapter of the CPLD Synthesis Design 
Guide. 
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Oscillator Functions (OSC, OSC4, OSC5) 

The OSC (X3000A/L), OSC4 (XC4000E/L/EX/XL/XV/XLA, 
Spartan, and SpailanXL) and OSC5 (XC5200) oscillator components 
do not have Verilog simulation models associated with them. For 
OSC, the clock signal frequency is derived from an external crystal- 
controlled oscillator. The OSC4 and OSC5 are internal oscillators, and 
are useful in applications in which timing is not critical. 

To simulate these oscillators, you must reference the net attached to 
the output of the oscillator component. For example, for an oscillator 
output net named osclk attached to an oscillator symbol (OSC, OSC4, 
or OSC5) with a timescale unit of Ins, use the Always block to 
emulate an oscillator with a 10 Mhz clock frequency. Toggle this net 
at the desired frequency in your Verilog test fixture using the Force 
command, as shown in the following example. 

force osclk = 1 'bQ; 

always »100 force osclk - -osclk; 

NGD2VER Notes 

Following are notes on NC.D2VER. 

Test Fixture File 

Hie end of the test fixture (TV) file produced by NGD2VER contains 
the following commands. 

UOOO Sstcp 
II H00Q Sfinish 

Tine Sstop command terminates simulation from the test fixture and 
places the simulator in "interactive mode". This mode allows you to 
view the waveforms produced or allows interaction with other 
programs that need the simulator open. 

You can terminate the Verilog simulator as follows. 

• In interactive mode, enter finish. 

• To exit automatically instead of entering interactive mode, edit 
the test fixture file to remove or comment out the is top line and 
uncomment the Sfinish line. 
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Bus Order in Verilog Files 

When you compile your unit-under-test design from NGD2VER 
along with your test fixture, there may be mismatches on bused 
ports. 

Tills problem occurs when your unit under test has top-level ports 
that are defined as LSB-to-MSB, as shown in the following example. 

Input (0:7) A; 

As a result of the way your input design was converted to a netlist 
before it was read into the Xilinx implementation software, the Xilinx 
design database does not include information on how bus direction 
was defined in the original design. When NGD2VER writes out a 
structural timing Verilog description, all buses are written as MSB-to- 
LSB. as shown in the following example. 

input (7:01 A; 

If your ports are defined as LSB-to-MSB in your original input design 
and test fixture, there is a port mismatch when the test fixture is 
compiled for timing simulation. Use one of the following methods to 
solve this problem. 

• In the test fixture, modify the instantiation of the unit under test 
so that all ports are defined as MSB-to-LSB for timing simulation 

• Define all ports as MSB-to-LSB in your original design and test 
fixture. For example, enter [7:0) instead of (0:7). 

Note: Bus order will be preserved if the design input file is ED1F and 
the buses are declared as port arrays, if you are doing logical simula¬ 
tion. or if you are doing back-annotation with an NGM file as input. 

Verilog Identifier Naming Conventions 

An identifier in a Verilog file must adhere to the following conven¬ 
tions. For more information see the IEEE Standard Description 
Language Based on the Verilog " Hardicare Description Linguage manual. 

• Must begin with an alphabetic or underscore character (a-z. A-Z. 

or J 

• Can contain the characters a-z. A-Z, 0-9, , or $ 

• May use any character by escaping with a backslash(\) at the 
beginning of the identifier, and terminating with a white space (a 
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blank, lab, newline, or formfeed). For example, the identifier 
reset' is not acceptable but the identifier \reset* is acceptable. 

• Can be up to 1024 characters long 

• Cannot contain white space 
Note: Identifiers are case sensitive. 

During the name legalization process, NGD2VER writes identifiers 
that contain invalid characters with a leading backslash and a 
following white space. If you want to change this default behavior, 
use the -ne option described in the "-lie (Replace Invalid Characters 
with Underscore)” section. 

Compile Scripts for Verilog Libraries 

You must compile libraries for your simulation tools to recognize 
Xilinx components. To perform timing or post-synthesis functional 
HDL simulation, you must compile the SimPrim libraries. If the HDL 
code contains instantiated components, you must compile the 
UniSim or LogiBLOX libraries. If the HDL code contains instantiated 
components from the CORE Generator System, you must compile the 
COREGen behavioral models before you can perform a behavioral 
simulation. Refer to the CORE Generator System User Guide for more 
information. 


To get compile scripts, go to the URLs shown in the following table. 

Table 20-1 Compile Script URLs 


Simulation Tool 

URL 

ModelSim Verilog 

http://support.xilinx.com/techdocs/1923Jitm 

N’C-Verikig 

http://support.xilinx.com/teehdocs/4S73.htm 


Note: You do not need to compile libraries for Verilog-XL 
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This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• Spartan2 

• SpartanXL 

• Virtex 

• XC9500 

• XC9500XL 

This chapter describes the NGD2VHDL program. The chapter 
contains the following sections. 

• “ NGD2VHDL" 

• "NGD2VHDL Syntax" 

• "NGD2VHDL Files” 

• " NGD2VHDL Options" 

• "VHDL Global Set/Reset Emulation" 

• "NGD2VHDL Notes" 
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Tile NGD2VHDL program translates your design into a VITAL 95 
IEEE compliant VHDL tile containing a netlist description o( the 
design in terms ol Xilinx simulation primitives. You can use the 
VHDL file to perform a back-end simulation by a VHDL simulator. 

Simulation is based on SimPrims. which create simulation models 
using basic simulation primitives. For example, a primitive for the 
XC4000 dual-port RAM does not exist in the VITAL SimPrim library 
files. Instead, if a dual-port RAM is needed, NGD2VHDL builds a 
simulation model for the dual port ram out of two 16x1 RAM 
SimPrim primitives. 

NGD2VHDL produces a VHDL file representing a design in any of 
the following stages. 

• An unmapped design—To translate an unmapped design, the 
input to NGD2VHDL Ls an NC.D file—a logical description of 
your design. Tine output from NGD2VHDL is a VHDL file 
containing a functional description of the design without timing 
information. 

• A mapped, unrouted design—To translate a mapped design 
which has not been placed and routed, the input to NGE*2VHDL 
is an NGA file— an annotated logical description of your 
design—generated from a mapped physical design. The output 
from NGD2VHDL is a VHDL file containing a functional descrip¬ 
tion of the design, and an additional SDF (Standard Delay 
Foimat) file containing timing information. The SDF file contains 
component delays without routing delays. 

• A routed design—To translate a design which has been placed 
and routed, the input to NGD2VHDL is an NGA file generated 
from a routed physical design. Tire output from NGD2VHDL is a 
V'HDL file containing a functional description of the design and 
an SDF file containing both component and routing delays. 

Tire design flow for NGD2VHDL is shown in the following figure. 
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Figure 21-1 NGD2VHDL Design Flow 


NGD2VHDL Syntax 

The following command translate*; your design to a VHDL file. 

ngd2vhdl [epfiows] infile[. ngd I . nga) |iwl/i7e|. vhd]] 

Options can be any number of the NGD2VHDL options listed in the 
"NGD2VHDL Options" section. They do not need to be listed in any 
pailicular order. Separate multiple options with spaces. 

Infite (. ngd I . nga] is the input NGD or NGA file. If you enter a file 
name without an extension. NGD2VHDL looks for a file with an .nga 
extension and the name you specified. If you want to translate an 
NGD file, you must enter the .ngd extension. Without the .ngd 
extension NGD2VHDL doe; not use the NGD file as input, even if an 
NGA file is not present. 

Oiif/i7c|.vhd| indicates the file to which the VHDL output of 
NGD2VHDL is written. Default is infile.vhd |infile is the same root 
name as the input file). Tine SDF file has the same root name as the 
VHDL file. 
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NGD2VHDL Files 

Tills section describes the NGD2VHDL input and output files. 

Input Files 

Input to NGD2VHDL can be any of the following files. 

• N'GA—a back-annotated logical design file containing Xilinx 
primitive components. 

• NGD—a logical design file containing Xilinx primitive compo¬ 
nents. 

Output Files 

Output from NGD2VHDL consists of the following flits. 

• VHD file—a VITAL 95 IEEE compliant VHDL file containing the 
netlist information obtained from the input NGD or NGA file. 
This file is a simulation model and cannot be synthesized or used 
in any other manner than simulation. This netlist uses simulation 
primitives which may not represent the true implementation of 
the device; however, the netlist represents a functional model of 
the implemented design. Do not modify this file. 

• SDF file—a Standard Delay Format file containing delays 
obtained from the input file. NGD2VHDL only generates an SDF 
file if the input is an NGA file, which contains timing informa¬ 
tion. The SDF file generated by NGD2VHDL is based on SDF 
version 2 . 1 . 

• LOG file—an optional log file created if you enter the -log option 
on the NGD2VHDL command line. It contains all the messages 
generated during the execution of NGD2VHDL. 

• PIN file—an optional Cadence signal-to-pin mapping file. 
NGD2VHDL generates a PIN file if the input file contains routed 
external pins and you have specified a -pf command line option. 

• Testbench file—an optional testbench file created if you enter the 
-tb option on the NGD2VHDL command line. The file has a 
.tvhd extension. 
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NGD2VHDL Options 

This section describes the NGD2VHDL command options. 

-a (Architecture Only) 

By default. NGD2VHDL generates both entities and architectures for 
the input design. If the -a option is specified, no entities are 
generated and only architectures appear in the output. 

-aka (Write Also-Known-As Names as Comments) 

The -aka option includes user-defined identifiers as comments in the 
VHDL netlist. This option is used if user-defined identifiers are 
changed because of name legalization processes in NGD2VHDL. 

-ar (Rename Architecture Name) 

-ar architecture name 

The -ar option allows you to rename the architecture name generated 
by NGD2VHDL. The default architecture name for each entity in the 
netlist is STRUCTURE. 

-f (Execute Commands File) 

-f command Jile 

The -f option executes the command line arguments in the specified 
command Jile. For mom information on the -f option, see the '-f 
Option" section of the "Introduction" chapter. 

-gp (Bring Out Global Reset Net as Port) 

-gp port_name 

The -gp option causes NGD2VHDL to bring out the global reset 
signal (which is connected to all flip-flops and latches in the physical 
design) as a port on the top-level entity in the output VHDL file. 
Specifying the port name allows you to match the port name you 
used in the front-end. The global reset signal is discussed in the 
"VHDL Global Set/Reset Emulation" section. 

Tills option is only used if the global reset net Ls not driven. For 
example, if you include a STARTUP component in an XC4000 design. 
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you do nol have to enter a -gp option, because the STARTUP compo¬ 
nent drives the global reset net. 

Note: Do not use C.R, GSR, PRELOAD, or RESET as port names, 
because these are reserved names In the Xilinx software. 

-log (Specify the Log File) 

-log logjile 

Tine -log option generates a log file that contains all of the messages 
displayed during the execution of NGD2VHDL. Specify the name of 
the log file. By default, the name is ngd2vhdl.log. 

-op (Specify the Period for Oscillator) 

-op oscillator_period 

Tine -op option specifies the period, in nanoseconds, for the oscillator. 
You must specify a positive integer to stimulate the component 
properly. If you do not enter a value for the -op option, the default is 

100 ns. 

-pf (Generate Pin File) 

The -pf option writes out a pin file—a Cadence signal-to-pin 
mapping file with a .pin extension. 

-pms (Port Names Match Child Signal Names) 

Tine -pms option forces the port names and child signal names to 
match. 

-r (Retain Hierarchy) 

Tine -r option writes out a VHDL file that retains the hierarchy in the 
original design as much as possible. Some loss of hierarchy may 
occur due to optimization. See the “Output Files" section of the 
"NGDAnno” chapter for more information. If loss of hierarchy 
occurs, NGD2YHD1. produces a warning for each level of user hier¬ 
archy that is lost. Following is an example. 
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WASHING:MgdHclF«rs:182 - Hierarchical block $1174/ 
£11128 has been flattened. The pins foe this block 
will not fcc observable in the generated simulation 
model. 

This option groups logic based on the original design hierarchy. To 
tun NGD2VHDL with the -r option, you should have supplied an 
NGM file as input when you ran NGDAnno (see the "Input Files” 
section ot the "NGDAnno" chapter). It you did not supply an NGM 
tile, the NGA file produced is based on the NCD tile, rather than the 
original design hierarchy. 

The default setting (with no -r option) products a flattened VHDL 
tile. 

-rpw (Specify the Pulse Width for ROC) 

-rpw mc_pulse_u'idth 

The -rpw option specifies the pulse width, in nanoseconds, tor the 
ROC component. You must specify a positive integer to stimulate the 
component properly. This option is not required. By default, the ROC 
pulse width is set to 100 ns. 

-tb (Generate Testbench File) 

Tine -tb option writes out a testbench tile with a .tvhd extension. 

The default top-level instance name within the testbench tile is UUT. 
If you enter a -ti (Top Instance Name) option, the top-level instance 
name is the name specified by the -ti option. 

-te (Top Entity Name) 

-te top_entityjuww 

Tine -te option specifies the name of the top-level entity in the 
structural VHDL file produced by NGD2VHDL for timing 
simulation. 

-ti (Top Instance Name) 

-ti topjnstancejume 

The -ti option specifies the name of the top-level instance name 
appearing within the output SDF file and testbench file (if produced). 
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Tine option allows you to match the top-level instance name to the 
name specified in your test driver VHDL file. Without this option, the 
SDF file generated by NGD2VHDL cannot be processed properly by 
VHDL simulators (for example. Model Technology vsim) for timing 
simulation. 

If you do not enter a -ti option, the output files contain a top-level 
instance name of UUT. 

-tp (Bring Out Global Tristate Net as Port) 

-tp portjume 

Tine -tp option causes NGD2VHDL to bring out the global trLstate 
signal (which forces all FPGA outputs to the high-impedance state) as 
a port on the top-level entity in the output VHDL file. Specifying the 
port name allows you to match the port name you used in the front- 
end. 

This option is only used if the global tristate net is not driven. For 
example, if you include a STARTUP component in an XC4000 design, 
you do not have to enter a -tp option, because the STARTUP compo¬ 
nent drives the global tristate net. 

-tpw (Specify the Pulse Width for TOC) 

-tpw loc_pulse_icidlh 

Tire -tpw option specifies the pulse width, in nanoseconds, for the 
TOC component. You must specify a positive integer to stimulate the 
component properly. This option is required when you instantiate 
the TOC component (for example, when the global set/reset and 
tristate nets are sourceless in the design). 

-verbose (Display Processing Messages in Verbose 
Mode) 

Tire -verbose option displays detailed VHDL processing messages 
when NGD2VHDL is run. 
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-w (Overwrite Existing Files) 

Tlio -w option causes NGD2VHDL lo overwrite the output tiles it 
they exist. By default (no-w specified) NGD2VHDL does not 
overwrite existing files. 

VHDL Global Set/Reset Emulation 

VHDL requites ports for all signals to be controlled by a testbench. 
There are VHDL specific components that can be instantiated in the 
RTL and post-synthesis VHDL description in order to enable the 
simulation of the global signals for Global Sot/Reset and Global Tri¬ 
state. NGD2VHDL creates a port on the back-annotated design entity 
for stimulating the global set/reset or tri-state enable signals. This 
port does not actually exist on the configured part. 

You do not need to use the -gp switch to create an external port if 
you instantiated a STARTUP block in the implemented design. In this 
case, the port is already identified and connected to the global set/ 
reset or tri-state enable signal. If you do not use the -gp option or a 
STARTUP block, you will need to use a special cell. Detailed direc¬ 
tions for specific emulation cells and their uses follow. 

Note: The term "STARTUP" refers to the STARTUP block for all 
device families, including the Virtex STARTUP block. 

STARTLP VIRTEX. The term ''STARTBUF" refers to the STARTBUF 
cell for all device families, including the Virtex STARTBUF cell. 
STARTBUF. VIRTEX. 

VHDL Only STARTUP Block 

Tire STARTUP block is traditionally instantiated to identify the GR. 
PRLD. or GSR signals for implementation. However, the only time 
simulation is enabled in the traditional method is when the net 
attached to the GSR or GTS also goes off chip, because the STARTUP 
block does not have simulation models. You can use the following 
new cells to simulate global set/reset or tri-state nets in all cases, 
whether or not the signal goes off chip. 

Note: The Virtex STARTU P block. STARTL P VIRTEX. is a subset of 
the XC4(XX) STARTUP block. It differs from the XC4000 STARTUP 
block in that is has no outputs, as shown in the following figure. 
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STARTUP STARTUP VTRTEX 



X8760 


Figure 21 -2 STARTUP and STARTUP_VIRTEX Blocks 

VHDL Only STARTBUF Cell 

Tlio STARTBUF cell passes a reset or tri-state signal in the same way 
that a buffer allows simulation to proceed, and it also instantiates the 
STARTUP block for implementation. STARTBUF is a more 
simulation friendly version of a typical STARTUP block. There is one 
version that works for all technologies, even though the XC52O0 and 
the XC4000 STARTUP blocks have different pin names. 
Implementation with the correct STARTUP block is handled 
automatically. An instantiation example for the STARTBUF cell 
follows. 

ul: STARTBUF port map (GSRIN => DEV_G3R_PORT, G7SIN 
=>DEV_GTS_PORT, CLKIN -> 'O', G3ROUT => GSR_tlET, 
GTSOUT => GTS_NET, 02OUT => open, C30UT => open, 
Q1Q4CUT -> open, DOHEINOUT -> open): 

One or both of the input ports GSR1N and C.TS1N of the STARTBUF 
component and the associated output ports GSROUT and GTSOUT 
can be used. The pins that are left "open" can be used to pass 
configuration instructions down to implementation, just as on a 
traditional STARTUP block. You can do this by connecting the 
appropriate signal to the port instead of leaving it in an "open" 
condition. 

Note: The STARTBUF VIRTEX cell is similar to the STARTBUF cell, 
but GSROUT is not available. 
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VHDL Only STARTUP_VIRTEX Block and 
STARTBUF VIRTEX Cell 

Global Set/Reset and Global Trislale tor the Virtex STARTUP block. 
STARTUP VIRTEX. and STARTBUF cell. STARTBUF VIRTEX. 
operate as described in the preceding sections with the following 
qualifications. 

• Pre-NGDBuild UniSim VHDL simulation of the GSR signal is not 
supported. 

Tine simulation libraries will start up in the correct state; 
however, you cannot reset the design after simulation time ' 0 / 

• During Pre-NGDBuild UniSim VHDL simulation, designs an? 
properly initialized at simulation time ' 0 .’ 

• Post-NGDBuild SimPrim VHDL simulation of GSR is supported. 

To correctly back-annotate a GSR signal, instantiate a 
STARTUP VIRTEX or STARTBUF VIRTEX symbol and 
correctly connect the GSR input signal of that component. When 
back-annotated, your GSR signal is correctly connected to the 
associated registers and RAM blocks. 

• Pre-NGDBuild UniSim VHDL simulation of the GTS signal is 
supported. 

Instantiate either a STARTBUF VIRTEX. TOC. or TOCBUF for 
this functionality. 

VHDL Only RESET-ON-CONFIGURATION (ROC) Cell 

This cell is created during back-annotation if you do not use the -gp 
option or STARTUP block options. It can be instantiated in the front 
end to match functionality with GSR, GR, or PRLD. (This Ls done in 
both functional and timing simulation.) During back-annotation, the 
entity and architecture for the ROC cell is placed in the design's 
output VHDL file. In the front end, the entity and architecture are in 
the UniSim Library, and require only a component instantiation. 

Tire ROC cell generates a one-time initial pulse to drive the GR. GSR, 
or PRLD net starting at time 'O' for a user-defined pulse width. You 
can set the pulse width with a generic in a configuration statement. 
The default value of "width" is 0 ns, which disables the ROC cell and 
results in the global set/reset being held Low. (Active-Low resets are 


Detvlopmenl System Reference Guide 


21-11 




Development System Reference Cuule 


handled wilhin the netlist itself and require you to invert this signal 
before using it.) 

The ROC cell allows you to simulate with the same testbench as in the 
KTL simulation, and also allows you to control the width of the 
global set/reset signal in the implemented design. 

Tine ROC components require a value for the generic WIDTH, usually 
specified with a configuration statement. Otherwise, a generic map Is 
required as part of the component instantiation. 

You can set the generic with any generic mapping method you 
choose. Set the ''width" generic after consulting The Programmable 
Logic Data Book for the particular part and mode you have 
implemented. 

For example, a XC4000E part can vary from 10 ms to 130 ms. The 
value to look for is the T roR (Power-ON Reset) parameter found in 
the Configuration Switching Characteristics tables for master, slave, 
and peripheral modes. 

One of the easiest methods for mapping the generic is a configuration 
for the user's testbench. An example testbench configuration for 
setting the generic is as follows. 

CONFIGURATION cfg_my_timing_tcsthcnch OF my_testbench 15 
FOR my_testbench_architecture 
FOR ALL:my_dcsign USE ENTITY work.mv_dcsign(structure); 

FOR structure 

FOR ALL:roc ENTITY USE work.roc <roc_v| 

Generic MAP (width => 100 ms>; 

END FOR; 

END FOR; 

END FOR; 

END FOR; 

END cfg_my_tim:ng_tcstbcnch; 

The following is an instantiation example for the ROC cell. 

Ul: ROC pert map (0 =>GSR_NET) ; 
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VHDL Only ROCBUF Cell 

Tine ROCBUF allows you lo provide stimulus for the Reset on 
Configuration signal through a testbench but the port connected to it 
is not implemented as a chip pin. The port can be brought back in the 
timing simulation with the -gp switch on NGD2VHDL. An example 
of instantiation of the ROCBUF cell follows. 

ul: ROCBUF port nap (I => SIM_GSR_PORT, O *> GSR_HETI; 

Note: This cell is not available for Virtex. 

VHDL Only Tri-State-On-Configuration (TOC) Cell 

This cell is created if you do not use the -tp or StartUp block options. 
The entity and architecture for the TOC cell is placed in the design’s 
output VHDL file. The TOC cell generates a one-time initial pulse to 
drive the GR. GSR, or PRLD net starting at time '0' for a user-defined 
pulse width. The pulse width can be set with a generic. The default 
value of "width" is 0 ns, which disables the TOC cell and results in 
the tri-state enable being held Low. (Active-Low tri-state enables are 
handled within the netlist itself and require you to invert this signal 
before using it.) 

The TOC cell allows you to simulate with the same testbench as in the 
RTL simulation, and also allows you to control the width of the tri¬ 
state enable signal in the implemented design. 

The TOC components require a value for the generic WIDTH, usually 
specified with a configuration statement. Otherwise, a generic map is 
requited as part of the component instantiation. 

You may set the generic with any generic mapping method you 
choose. Set the "width" generic after consulting The Programmable 
Logic Dahl Book for the particular part and mode you have 
implemented. 

For example, a XC4000E part can vary from 10 ms to 130 ms. The 
value to look for is the T roR (Power-ON Reset) parameter found in 
the Configuration Switching Characteristics tables for master, slave, 
and peripheral modes. 

One of the easiest methods for mapping the generic is a configuration 
for the user’s testbench. An example testbench configuration for 
setting the generic is as follows. 
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CONFIGURATION c£g_my_timing_tC5t bench OF my_t cstbcnch IS 
FOR my_teatbcnch^architecture 
FOR ALL:my_design USE ENTITY work.my_dcsign(structruel; 

FOR structure 

FOR ALL:toe ENTITY USE work.toe <toc_v» 

Generic MAP (width => 100 ms); 

END FOR; 

END FOR; 

END FOR; 

END FOR; 

END c£g__my_timmg_tcstbench; 

An instantiation example of the TOC cell follows. 

U2: TOC pert map (O -> GTS_.NET); 

VHDL Only TOCBUF 

Tine TOCBUF allows you lo provide stimulus for the global tri-state 
signal (GTS) through a testbench but the port connected to it is not 
implemented as a chip pin. The port can be brought back in the 
timing simulation with the -tp switch on NGD2VHDL An example 
of the instantiation of the TOCBUF cell follows. 

U2: TOCBUF port, nap (E ->SIM_GTS_PORT. O =>GTS_HE7) ; 

VHDL Only Oscillators 

Oscillator output can vary within a fixed range. The cell is not 
included in the SimPrim library, because you cannot drive global 
signals in VHDL designs. Schematic simulators can define and drive 
global nets so the cell is not required. Verilog has the ability to drive 
nets within a lower level module as well. Therefore the oscillator cells 
are only required in VHDL. After back-annotation, their entity and 
architectures are contained in the design’s VHDL output. 

For functional simulation, they may be instantiated and simulated 
with the UniSim Library. 

The period of the base frequency must be set in order for the 
simulation to proceed, because the default period of 0 ns disables the 
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oscillator The oscillator's frequency can very significantly with 
process and temperature. 

Before you set the base period parameter, consult The Programmable 
Logic Diitii Book for the particular part you are using. For example, the 
section in The Programmable Logic Data Book for the XC4000 Series On- 
Chip Oscillator states that the base frequency can vary from 4MHz to 
It) MHz, and is nominally 8 MHz. This means the base peiiod generic 
"period 8m” in the XC4000E OSC4 VHDL model can range from 250 
ns to 100ns. An example of this follows. 

Note: This cell is not available for Virtex. 

Example 1: Oscillator VHDL 

library IEEE; 

use IEEE.std_lcgic_1164.all; 
use IEEE.std_legic_unsigned.all; 


library UNISIM; 
use UNZSXM.allf 


entity tcstl is 
port <DATAIN: in STD_LC* 
DATACCT: cut S7D_LOGIC»; 
end tcstl; 


architecture inside of tcstl is 

signal RST: STD_L03IC; 

corpcnent RCC 

port(O: out STD_LCGIC); 

end conponcnt; 
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component OSC4 
port(F8M: out 3TD_LCGIC); 
end conponcnt; 

signal intomalelocks 3TD_LCGIC; 
begin 

UO: ROC pert map (R3T); 

. GSC4 port map <FflM=>internalclock); 

process(internalclock) 
begin 

if (RST=' V) then 
DATAOUT <= 'O'; 

els if<internalclock*event and internalcicck^' 1 ') then 
DATACOT <= DATAXN; 

end if; 

end process; 

end inside; 
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Example 2: Oscillator Test Bench 

library IEEE; 

use IEEE.std_lcgic_1164.all; 
use IEEE.st d_legic_unsigned.all; 

library UNISIM; 
use UNISIM.all; 

entity tcst_oftcstl is end test_oftest 1 ; 

architecture inside of tcst — oftcstl is 

component tcstl 

port(DATAIN: in STD_LOGIC; 

DATACXJT: cut STD_l>DGIC»; 
end conponcnt; 

signal userdata, userout: STD_LOGIC; 

begin 

UUT: test 1 port nap(DATAIN=>uscrdata,DATAOUT=>uscrout); 

myinput: process 
begin 

userdata <= ' 1 '; 
wait for 299 ns; 
userdata <= 'O'; 
wait for 501 ns; 
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end process; 

end inside; 

configuration overall of test_oftest 1 is 
for inside 

for UUT:tcstl 

for inside 

for U0:ROC use entity UN1SXM.ROC(RCC_V) 
generic nap <XIDTH=> 52 ns); 
end for; 


for Ul:OSC4 use entity UNXS2M.OSC4(OSC4_V) 
generic nap <PERIOD_0M=> 25 ns); 
end for; 
end for; 
end for; 
end for; 
end overall; 

This configuration is for pre-NGDBuild simulation. A similar 
configuration is used for post-NGDBuild simulation. The ROC, TOC, 
and OSC4 an? mapped to the WORK library, and corresponding 
architecture names may be different. Review the .vhd file created by 
NGD2VHDL for the current entity and architecture names for post- 
NGDBuild simulation. 

NGD2VHDL Notes 

Following are notes on NGD2VHDL. 

Bus Order in VHDL Files 

When you compile your unit-under-test design from NGD2VHDI. 
with your testbench, there may be mismatches on bused ports. 
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Tills problem occurs when your unil under lesl has lop-level ports 
Hull are defined as LSB-lo-MSB, as shown in Ihe following example. 

A: in STD_L0GIC_V£C70R <0 to 7); 

As a result of Ihe way your input design was converted to a netlist 
before it was read into the Xilinx implementation software, the Xilinx 
design database does not include information on how bus direction 
was defined in the original design. When NGD2VHDL writes out a 
structural timing VHDL description, all buses are written as MSB-to- 
LSB, as shown in the following example. 

A: in STD_LOGIC_V£CTOR (7 dcwnto 0)j 

If your ports were defined as LSB-to-MSB in your original input 
design and testbench, there is a port mismatch when the testbench is 
compiled for timing simulation. Use one of the following to solve this 
problem. 

• In Ihe testbench, modify the instantiation of the unit under test so 
that all ports are defined as MSB-to-LSB for timing simulation 

• Define all ports as MSB-to-LSB in the original design and 
testbench, by using the downto clause instead of the to clause to 
specify a bus range. 

Note: Bus order will be preserved if the design input file is ED1F and 
the buses are declared as port arrays, if you are doing logical simula¬ 
tion. or if you are doing back-annotation with an NGM file as input. 

VHDL Identifier Naming Conventions 

An identifier in a VHDL file must adhere to the following conven¬ 
tions. For more information see the IEEE Standard VHDL Language 
Reference .Manual or the IEEE Standard VITAL Application-Specific Inte¬ 
grated Circuit (ASIC) Modeling Specification. 

• Must begin with alphabetic characters (a-z or A-Z) 

• Can contain the characters a-z. A-Z, 0-9, or 

• Can be up to 1024 characters long 

• Cannot contain white space 
Note: Identifiers are not case sensitive. 

During the name legalization process, NGD2VHDL substitutes any 
illegal characters with the underscore (_) character. 
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Compile Scripts for VHDL Libraries 

You must compile libraries for your Simula (ion loo Is to recognize 
Xilinx components. To perform liming or post-synthesis functional 
HDL simulation, you must compile the SimPrim libraries. If the HDL 
code contains instantiated components, you must compile the 
UniSim or LogiBLOX libraries. If the HDL code contains instantiated 
components from the CORE Generator System, you must compile the 
COREGen behavioral models before you can perform a behavioral 
simulation. Refer to the CORE Generator System User Guide for more 
information. 

To get the necessary compile scripts for ModelSim VHDL, go to 
http://support. xiIinx.com/techdocs/ 1923.htm. 
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XFLOW _ 

XFLOW is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan/XL/2 

• Virtex 

• XC9500 

• XC9500XL 

Tine chapter contains the following sections. 

• "Overview" 

• "XFLOW Syntax" 

• "Flow Types" 

• "Option Files" 

• "XFLOW Options" 

• "Input Files" 

• "Output Files" 
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Overview 

The purpose of XFLOW is to provide a mechanism lor users to 
encapsulate the Xilinx implementation or simulation flows within 
their own tools. These user tools might be simple scripts or they 
might be company frameworks. 

XFLOW is a command line tool that allows you to run the full suite of 
Xilinx implementation and simulation flows. To run, XFLOW reads a 
design file, flow file, and option files as inputs. Tire flow file specifies 
the sequence of Xilinx tools to run on a design. The option file 
specifies the command line options for all the tools listed in the flow 
file. Xilinx has provided six option files for implementation —three 
each for FPGAs and CPLDs and numerous option files for 
simulation. See the "Option Files" section for a list of these files. 
Xilinx has also provided three flow files to perform some basic 
implementation sequences. See the "Flow Files" section for a list. 

If you run XFLOW on a design for the first time, XFLOW searches 
through the hierarchy and copies the corresponding flow and option 
files into your working directory. For later runs with the same 
command line options, XFLOW searches through your install 
hierarchy (or trce) and copies the flow files and option files. The 
hierarchical search is as follows: 

• Currcnt working directory (First) 

• Directories specified with the XFLOWPATH environment 
variable. This variable is used to define implementations for 
project-based, team-based, or company-wide settings. For 
example, consider a project team working on a design. If a project 
team has decided on the flow file and options file to use, the team 
can keep these files in a central repository pointed to by the 
XFLOWPATH environment variable. The variable ensures tliul 
the team members will run the same flow with the 
predetermined options which avoids inconsistencies. 

• User-defined area specified by the MYXILINX environment 
variable 

• Installed area specified with the XILINX environment variable 
(Last) 
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If the design is an FPGA and you are using Ihe -implement, -tsim, or 
-config flow typos, the default flow file is fpga.flw. If the design is a 
CPLD and you are using the -fit or -tsim options, the default file is 
cpld.flw. If you are running a functional simulation for either an 
FPGA or CPLD using the -fsim flow type, the default flow file is 
fsim.flw. 

XFLOW executes the programs in the order specified in the flow file. 
It checks the options file to find the corresponding options for each 
program in the flow file. 



UOU 


Figure 22-1 XFLOW 
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XFLOW Syntax 

Following is the syntax for XFLOW. 

xf low \floiv fy/'i’l |opIfoN/r7e| [xflow option] tlesign juvne 

The combined syntax of theflim* type and option file runs the Xilinx 
command line tools. The following table illustrates the relationship 
between each flow type and its option file. Xilinx provides the option 
files listed in the table for each flow type. You can also create your 
own option files. 

Note: This chapter uses the UNIX command line syntax. UNIX 
platforms use a slash (/> to specify a directory path while PCs use < 
backslash (\). Make sure that you use the correct syntax for your 
platform. 


flow types 

option file 

-implement 

fast runtime.opt 


balanced.opt 


high effort.opt 

-tsim 

See the "Option Simulation Files" table. 

-config 

bitgen.opt 

-fit 

balanced.opt 


speed .opt 


density.opt 

-fsim 

See the "Option Simulation Files" table. 


Ftoio type can be any of those listed in the "Flow Types" section. You 
must specify at least one of these five flow types when running 
XFLOW: -implement, -fsim, -tsim, -fit, or -config. Each of these flow 
types require a file argument, for example. -Implement 
balanced.opt. 

Note: Tine -fsim flow type cannot be used with the -implement, -tsim. 
-fit, or -config flow types. 

An option file must be specified for each flow type. See the "Option 
Files" section for details. 
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An xflow option can be any of Ihe options listed in the following table: 


XFLOW 

Options 

Arguments 

Description 

-ed 

exfwrt directory 

Copies export files to the export 
directory 

-h 


Displays help/usage message 

-norun 


Creates flow, option, and script 
files in the working directory and 
then stops. 

-o 

output . filename 

Clranges output file name 

-p 

partname 

Specifies a part name 

-rd 

rffiorl directory 

Copies report files to the 
report -directory 

-wd 

working-directory 

Specifies a working directory 


Options can be listed in any patticulai order. Separate multiple 
options with spaces. The design name is Ihe only required input file. 
See the "Input Files" section for a description of input design file 
formats. 

Example 1 

Tire following example shows how to use the -implement flow type. 

xflow -p xcvl00bg256-5 -implement balanced, (opt] 
testclk.edf 

XFLOW searches for the fpga.flw and balanced.opt files in the 
working directory. If these files cannot be found in the working 
directory, XFLOW copies the files to the working directory from the 
install area and then executes the programs specified in the flow file. 
Note that you must have a file argument for the -implement flow 
type. 

Example 2 

Tire following example shows how to use a combination of flow 
types to implement, configure, and perform an ED1F timing 
simulation on an FPGA. 
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xflow -p xcvl00bg256-5-implement balanced].opt|- 
tsim genetic edif|. opt|-config bitgen[.opt] 
testclk.edf 

Example 3 

Tine following example shows how lo use a combination of flow 
types to fit and perform a VHDL timing simulation on a CPLD. 

xflow -p xc95144pql60-7 -fit balancedl. opt| -tsim 
generic vhdl[.opt] main pcb.edn 


Flow Types 

Following is a description of the flow types and how they affect the 
behavior of XFLOVV For a desired flow, select a combination of the 
-implement, -tsim, -fit, -fsim, and -config flow types. 

Note: The -fsim flow type must be used by itself and cannot be 
combined with the -implement, -tsim, -fit, or -config flow types. 

You do not need to specify the complete path for option files on the 
command line. XFLOW searches for option files in the following 
hierarchy: 

• Current working directory (first) 

• Directories specified using XFLOVV'PATH 

• SMYX1LINX 

• SX1L1NX (last) 

If you want to create your own option files, Xilinx recommends that 
you make a copy of an existing file, rename it option Jile. opt, and then 
modify it. 

-config (Create a BIT File for FPGAs) 

-config option Jile [. opt | 

This flow type creates a bitstream for FPGA device configuration. The 
-config flow type automatically invokes the fpga.flw flow file in the 
SXILINX/xilinx/data directory. The flow file runs only B1TC.EN. 

Xilinx provides the bitgen.opt option file as the only option, file in the 
$XlLlNX/xilinx/data directory. 
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Note: The -config flow type requites a file name argument. There is 
no implied default. 

Example: 

Tine following example shows how to use a combination of flow 
types to implement and configure an FPGA. 

xf low -p xcvl00bg256-5 -implement balanced]. opt | 
-config bitgen|. opt| testclk. edf 

-fit (Fit a CPLD Device) 

-fit option Jile[ . opt| 

This flow type incorporates logic from a design into physical 
macrocell locations in a CPLD. Routing is performed automatically. 

Xilinx provides three files as option Jilts in the $XILlNX/epld/data 
directory. These files are shown in the following table. 


Table 22-1 Option Files for -fit 


Option Files 

Description 

balanced.opt 

balanced between speed and density 

speed .opt 

optimized for speed 

density.opt 

optimized for density 


Tine -fit flow type automatically copies the cpld.flw flow file from the 
SXlLlNX/epld/data directory. Tine flow file runs the ngdbuild. hitop. 
taengine, hprep sequence. 


Note: The -fit flow type requires a file name argument. There is no 
implied default. 

Example: 

Tine following example shows how to use a combination of flow 
types to fit and perform a VHDL tinning simulation on a CPLD. 

xf low -p xc95144pql60-7 -fit balanced]. opt]-tsim 
genetic vhdl|.opl| main pcb.edn 
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-fsim (Perform a Functional Simulation) 

-f sim cp# ion_fiU\ .opt| 

Tills flow type performs a functional simulation for FPGA or CPLD 
designs. 

Xilinx provides FPGA option files in the SXILINX/xilinx/data 
directory and CPLD option, files in SXlLlNX/epld/data. The 
following table summarizes these option files. 

Table 22-2 Option Simulation Files 


Flow Name 

Family 

Option File 

Description 

VHDL Functional/ 
Timing 

Simulation 

FPGA/ 

CPLD 

generic vhdl.opt 

Generic VHDL 

active, vhdl.opt 

Active VHDL 

modelsim vhdl.opt 

Modelsim VHDL 

vss_vhdl.opt 

VSS VHDL 

speed wave vhdl.opt 

Speedwave VHDL 

Verilog Functional/ 
Timing 

Simulation 

FPC.A/ 

CPLD 

generic_verilog.opt 

Generic Verilog 

modelsim verilog.opt 

Modelsim Verilog 

concept nc verilog.opt 

Concept-NC Verilog 

concept .verilog xl.opt 

Concept Verilog-XL 

nc.verilog.opt 

NC Verilog 

verilog xl.opt 

Verilog-XL 

vcs_verilog.opt 

VCS Verilog 

ED1F Functional/ 
Timing Simulation 
Flow 

FPC.A/ 

CPLD 

generic edif.opt 

Generic EDIF 

fndtn edif.opt 

Foundation EDIF 

viewsim edif.opt 

Viewsim EDIF 

quicksim edif.opt 

Quicksim EDIF 


Note: The -fsim flow type requires a file name argument. There is no 
implied default. Also, you cannot use this flow type in conjunction 
with the -implement, -tsim, -config, or -fit flow types. 


The following example show how to perform an ED1F functional 
simulation on an FPGA. 

xflow -p xcvl00bg256-5 -fsim generic edif[.opt] 
testclk.edf 
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-implement (Run FPGA implementation) 

- implement opthin_file{ . opt) 

Xilinx provides three option Jiles in the $XlLINX/xilinx/data 
directory. The -implement (low type automatically invokes the 
fpga.flw flow file in the SXILINX/xilinx/data directory. The flow file 
runs ngdbuild. map. tree, par, and tree. 

Note: The -implement flow type requires a file name argument. 
There is no implied default. 

The following table shows the option files provided by Xilinx. 

Table 22-3 Option Files for -implement 


Option Files 

Family 

Description 

fast runtime.opt 

FPGA 

Runs the software tools non- 
timing driven. This option file 
provides the fastest runtimes at 
the expense of design perfor¬ 
mance. It Ls recommended for 
medium to slow speed designs. 

balanced.opt 

FPGA 

Runs at PAR Effort Level 2. 
Operates at a level between 
fast .runtime.opt and 
high effort.opt 

high effort.opt 

FPGA 

Runs the software tools timing 
driven at PAR Effort Level 4. 

High effort creates longer 
runtimes. It is recommended for 
creating designs that operate at 
high speeds. 


The following example show how to use the -implement flow type. 


xflow -p xcvl00bg256-5 -implement balanced]. opt| 
testclk.edf 
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XFLOVV searches for the fpga.flw and balanced.opl files in Ihe 
working directory If these files cannot be found in the working 
directory, XFLOW copies the files to the working directory from 
either the path specified by the XFLOWPATH environment variable 
the install area and then executes the programs specified in Ihe flow 
file. Note that you must have a file argument for the -implement flow 
type. 

-tsim (Perform a Timing Simulation) 

-1 a im cf 1 /ion file\ . opt | 

Tills flow type performs a timing simulation for FPGA or CPLD 
designs. 

Xilinx provides FPGA optionJiles in the SXILINX/xilinx/data 
directory and CPLD option Jiles in SXlLlNX/epld/data. See the 
"Option Simulation Files” table for a list of the files. 

Note: The -tsim flow type requires a file name argument. There is no 
implied default. 

Example: 

Tine following example shows how to use a combination of flow 
types to fit and perform a VHDL timing simulation on a CPLD. 

xflow -p xc95144pql60-7 -fit balanced.opt -tsim 
generic vhdl.opt main pcb.edn 

Option Files 

Tine options for all programs that are part of a flow are contained in 
option files. These files have an .opt extension. Xilinx provides option 
files for each flow type. Refer to the previous flow file subsections for 
a listing of tine installed option files. 

• -config (Create a BIT File for FPC.As) 

• -fit (Fit a CPLD Device) 

• -fsinn (Perform a Functional Simulation) 

• -implement (Run FPGA implementation) 

• -tsim (Perform a Timing Simulation) 
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The option files are located in the $XILLNX/xilinx/data or SXIL1NX/ 
epld/data directories.The option file data is in ASCII format, which 
can be edited. 

Option File Structure and Content 

For each program in the flow file, the option file has a corresponding 
program block. This block lists the default command line options that 
are enabled. Preceding each block is a comment section with help 
messages to obtain the list of all command line options for a program. 

Options in the option file can be switches, files, or parameter files. 

• Switches 

Switches that do not require any arguments, that is, the switch 
enables or disables a specific operation. For example, -r 

Switches that require one or more arguments that are strings or 
integers. For example, -pi 5 or -cm area. 

Switches that accept values in the format option value : value. For 
example, -g DonePirePULLUP; 

• Files 

This category includes command line options that are just file 
names. 

Example; 

calc.pcf; 

• Parameter files 

Tills category specifies parameters for programs in a flow. All the 
parameters are written into a file. 

Example; 

CTL file for program hitop for CPLD devices. The option file for 
CPLD flow has the following entry for program ’hitop" to create 
the CTL file. 

Progran hitop 

-f <design>.ngd; 

-d <design>; 

-1 <dcsign>.log 
ParamFilc: <dcoign>.cti 
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H DT_SYNTHESIS:TRUE*; 

"»r9500_INPUT_LIMIT: 36*; 

"GSR_OPT; TRUE"; 

End ParamFilc 
End Program hitop 

For this example, XFLOYV creates a CTL file, design.cti with all the 
parameters listed in the option file. 

Option File Sample 

Following Is an option file, balanced .opt, that is used with the 
-implement flow type. For the most up-to-date version of the file, see 
the file located in SXILINX/xilinx/data. 


FL0M7YPE = FPGA; 
it Filename: balanced.opt 

It 

it Option File For Xiiinx FPGA Implcncntation Flow 
it ^Header: /dev1/xcs /repo/cnv/Jobs/Xf1ow/data/optlonf iles/Attic/ 
£pga_balanccd.cpt,v 1.1.4.1 1999/03/04 02:33:19 jayr Exp $ 
it Version: 1.0.0 

itlttiitlitiit<lit^titit«ttitlttittttitlttilttittttitilttitiitittitit 


i Options for Translator 


i 

i Type "ngdbuild -h" for a detailed list of ngdbuild coirmand line options 

i 


Progran ngdbuild 
-p <partname>; 
-nt tincstanp; 


-u; 

<uscrdosign>; 
<dcsign>.ngd; 

End Program ngdbuild 


t Part name to use - picked from xflovc conmandiinc 
t NOD File generation. Regenerate only when 
t source netlist is newer than existing 
t NGO file {default) 

t Allow unexpanded blocks in output WGD design 
t User design - pick from xflovc ccmnand line 
i Name of NGD file. Filebasc sane as design filebase 


i 

i Options for Mapper 

i 

i Type "map -h <arch>* for a detailed list of map corrmand line options 

i 

Progran map 

-o <dcsign>_map.ned; t Output Mapped ned file 
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<dcsign>.ngd; 4 Input NGD file 

<dcsign>.pcf; 4 Physical constraints tile 

END Program map 

I 

4 Options for Post Wap Trace 

* 

4 Type "tree -h" for a detailed list of tree corrmand line options 

4 

Progran pcst_map_trcc 

-e 3; 4 Produce level 3 error report 

-o <dcsign>_ map.twr; 4 Output trace report file 
<dcsign>_rThap . nca; I Input mapped ned 

<dcsign> .pcf; 4 Physical constraints file 

END Program post_map_tree 


I 

4 Options for Place and Route 

4 

4 Type "par -h* for a detailed list of par corrmand line options 

* 


Progran par 
-w; 

-ol 2 ; 

-d 0; 

<design >_map.ned; 
<dcsign>.ned; 
<dcsign>.pcf; 

END Program par 


4 Overwrite existing placed and routed ned 
4 Overall effort level 

4 Nunber of delay based cleanup passes 
4 Input mapped NCD file 
4 Output placed and routed NCD 
4 Input physical constraints file 


i 

4 Options for Post Par Trace 

4 

4 Type "tree -h" for a detailed list of tree corrmand line options 

4 


Progran post_par__trcc 

-e 3j 4 Produce level 3 error report 

-o <dcsign>.twr; 4 Output trace report file 

<dcsign>.ned; 4 Input placed and routed ned 

<design>.pcf; t Physical constraints file 

END Program post_par_tree 
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XFLOW Options 

Tills section describes the xfloio options. These options can be used 
with any of the flow types and their arguments. 

-ed (Copy Files to Export Directory) 

-ed export .directory 

Tills option copies files specified in the export section of a flow file to 
the export-directory The default is the working directory. See the 
"Row Files" section for a description of the export section of the flow 
file. 

If you use the -ed export directory option with the -wd 
working directory option and do not specify an absolute pathname for 
the export-directory, the directory is placed underneath the 
uorking^directory. For example, 

xflow -p xcvl00bg256-5 -implement balanced! .opt]-wd 
sub3 -ed export3 testclk.edf 

Tlie export.! directory is created if it does not already exist 
underneath the sub3 directory. 

If you do not want the export directory to be a subdirectory of the 
working directory, enter an absolute pathname. For example. 

xflow -p xcvl00bg256-5 -implement balanced.opt -wd 
sub3 -ed /usr/export3 testclk.edf 

-h (Help) 

The -h option displays a list of valid options with brief 
descriptions. 

-norun (Creates a Script File) 

By default. XFLOW begins executing programs that are enabled in 
the flow file. If you do not want program execution to begin, specify 
the -norun option. XFLOW then creates test flow and option files 
listing the command lines for all the enabled program and then stops. 

Tire following example shows how to use the -norun option to create 
the initial flow and options files in the working directory and then 
stop. 
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xflow -p xcvl00bg256-5 -implement balanced, [opt| 
-norun testclk.edf 

This example copies the balanced.opt and fpga.flw files to the current 
directory. The example command also creates the following script 
file: 

********4t# *******4****4****4****4*******4* 

4 Script tile to run the flow 

4 

4******** ************** 4********* ********** 

* 

* Corrmand line for ngdbuild 

* 

ngdbuild -p xcvl00bg2S6-5 -nt timestarrp /home/ 
xflow^test/testclk.edf testclk.ngd 

I 

* Corrmand line for map 

* 

map -o testclk_map.ned testclk.ngd tostelk.pet 

* 

* Corrmand line for par 

* 

par —w -ol 2 -d 0 tcstclk_nap.ned tcstclk.ncd 
tostclk.pcf 

4 

* Corrmand line for post_par_trcc 

4 

tree -o 1 -o testclk. tver tcstclk.ncd test elk. pcf 

-o (Change Output File Name) 

-o output ^filename 

This option allows you lo change the output file base name. If you do 
not specify this option, the output file name will have the base name 
of the input file. 

Tine following example show how to use the -o option to change the 
base name of output files. 

xflow -p xcvl00bg256-5 -implement balanced]. opt| -o 
newname testclk.edf 

All output files have the base name "newname" instead of "testclk". 


Development System Reference Guide 


22-15 




Development System Reference Guide 


-p (Enter a Part Name) 

-p partnante 

Tlie -p option allows you to specify a device. For a list of valid 
options, see the "Part Numbers in Commands" section of the "Intro¬ 
duction" chapter. 

For FPGA part types, you must designate a part name with a package 
name. If you do not. XFLOVV halts at map indicating that a package 
needs to be specified. (You can obtain package nanus for installed 
devices using the PARTGEN command with the -i option.) 

If the -p option is not specified, one of the following occurs: 

• XFLOVV searches for the part name in the input design file. If 
XFLOVV finds a part number, it uses that number as the target 
device for the design. 

• If XFLOVV does not find a part number in the design input file, it 
prints an error message indicating that a part number is missing. 

Note: If the design is a CPLD, either the part number or the family 
name can be specified. 

The following example show how to use the -p option for a Virtex 
design. 

xflow -p xcvl00bg256-5 -implement high effort.opt 
testclk.edf 

-rd (Copy Report Files) 

-rd report dilatory 

The -rd option copies the reports specified in the report section of the 
of the flow file to the rc/iorl directory. The default refxirt directory is 
the working directory. 

If you use the -rd re/>ort directory option with the -wd 
working directory option and do not specify an absolute pathname for 
the report directory the directory is placed underneath the 
working jtireclory. For example. 

xflow -p xcvl00bg256-5 -implement balanced.opt -wd 
sub3 -rd report3 testclk.edf 
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The repor(3 directory is created, if it does not already exist, under¬ 
neath the sub3 directory. 

If you do want the report directory to be a subdirectory of the 
working directory, enter an absolute pathname. For example. 

xflow -p xcvl00bg256-5 -implement balanced.opt -wd 
sub3 -rd /usr/report3 testclk.edf 

Refer to the following for a list of FPGA and CPLD report files; 

• "FPGA Programming Data" table 

• "CPLD Programming Data" table 

-wd (Specify a Working Directory) 

-wd working _direclory 

Tire -wd option defines a working directory. Tire default is the 
current directory. If no path is specified for the working jtireclory, then 
the directory is created, if it does not already exist, in the current 
working directory and all generated files are placed in the new direc¬ 
tory. For example, assume that your current working directory is 
named "project", your design name is "test dock.edif" and you enter 
the following command: 

xflow -p xcvl00bg256-5 -fsim genetic edif.opt - 
wd subl testclk.edf 

Tire directory subl is created, if it does not already exist, and all the 
files generated from XFLOW are placed in the subl directory. 
Following is a list of the files for the example. 

• fsim.flw 

• netlist.lst 

• tesLcloek.ngo 

• func sim.edn 

• test.clock.bld 

• xflow.log 

• generic _ edif.opt 

• test clock.ngd 
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• xfknw.scr 

You can also enter an absolute path lor a working directory Following 
is an example lor an existing directory, /usr/projectl. 

xflow -p xcvl00bg256-5 -fsim genetic edit.opt - 
vd /usr/projectl testclk.edf 

In this example, all generated tiles are placed in /usr/projectl. 

Input Files 

Tine inputs to XFLOW am a user input lile, a flow tile, and one or 
more option liles-The How lile is automatically utilized when 
specifying a flow type—implement, tsim, conlig, fit, or Isinn. 

User Input Design File 

Tine only required input file to XFLOW is an input design lile. This 
design lile can be an ED1F or X\'F netlist, a PLD file, an NGD lile, or 
NCD file. The following table indicates valid input files. The input 
file must be in one of these formats. 

An input netlist file usually has a top-level module and several sub¬ 
design modules. The top-level file must be in one of the supported 
formats. Tine sub-design modules can be in other formats such as 
Verilog and VHDL 

Table 22-4 Valid Input Files 


File Type 

Syntax 

Location 

F.D1F Netlist 

*.edf 



*.edn 

*.edif 

'.sedif 

Current working directory 

XNF Netlist 

*.xnf 



*.xtf 

*.sxnf 

Current working director)' 

PLD File 

•.pld 

Current working directory 

NGD File 

*.ngd 

Current working directory 

NCD File 

‘.ncd 

Current working directory 
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Tine UCF file allows you lo specify constraints independently of an 
input netlisl file. There can only be one UCF file per design. The UCF 
file will be read automatically by NGDBuild if the file resides in the 
same directory and has the same base name as the input design file. If 
the UCF file must have a different base name than an input netlist 
file, you can modify the -uc option for NGDBuild in an option file to 
read the UCF file. 

All other input files are specified as arguments to the options. These 
option files are described in the "Option Files" section. 

N'GD files or NCD files can also be used as input files if you want to 
start the flow at an intermediate point such as MAP or PAR, rather 
than at the beginning stage with an ED1F or XMF netlist. 

Flow Files 

Tire following subsections describe the flow file and provide an 
example. 

Description 

All designs targeted for Xilinx devices follow a flow. A flow is a 
sequence of programs that are automatically invoked to implement, 
configure, and simulate a design. For example, to prepare an FPGA 
design for VHDL timing simulation, run the design through 
ngdbuild. map, par, ngdanno. and ngd2vhdl program flow. This 
sample flow requires the use of the -implement and -tsim flow types. 

If you select either the -implement, -fit. -config -tsim, or -fsim flow 
type. XFLOW automatically invokes one of the Xilinx flow files. The 
following table shows which flow files are invoked for each flow 
type. 
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Table 22-5 Xilinx Flow Files 


Family 

Flow Name 

Flow Type 

Flow Phase 

Programs 

FPGA 

fpga.flw 

-implement 

Implementation 

ngdbuild. map, tree, par, tree 

-tsim 

Timing 

Simulation 

ngdanno. ngd 2 edif. ngd 2 ver. 
ngd 2 vhdl 

-config 

Configuration 

bitgen 

CPLD 

cpld.flw 

-fit 

Fit 

ngdbuild. hitop. taengine. 
hprep6 

-tsim 

Timing 

Simulation 

tsim. ngd 2 edif, ngd 2 ver, 
ngd 2 vhdl 

FPGA/ 

CPLD 

fsim.flw 

-fsim 

Functional 

Simulation 

ngdbuild. ngd 2 edif, ngd 2 ver. 
ngd 2 vhdl 


Note: Invoked programs depend on which option file is used with 
each flow type. See the "Option Files" section lor details about option 
files. 


Tine flow file, which is ASCII format, contains the following 
information. 

• ExportDir 

Tine directory in which to copy the outputs of individual 
programs in the flow. Tine output files are specified under the 
Exports option in the program block. ExportDir defaults to your 
working directory. You can also specify the export directory 
using the -ed command line option. Tine command line overrides 
any Export directory in a flow file. 

• Report Dir 

Tine directoiy in which to copy the report files generated by the 
programs in the flow. Tine report files are specified under the 
Reports option in the program block. Report Dir defaults to your 
working directory. You can also specify the report directory 
using the -rd command line option. The command line overrides 
any Report directory in a flow file. 
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• Program block for each executable in the flow 
Each program has the following information. 

• Program program jiame 

Tire name of the program, for example, ngdbuild. The 
Program statement is the first line of the Program block. The 
last line of a Program block is End Program. 

• Flag: ENABLED I DISABLED 

ENABLED: Only run the program if there are options in the 
options file. 

DISABLED: Do not run the program even if there are options 
in the options file. 

• Input -.filename 

Tlie name of the input file for the program. For example, for 
the map program, the input file is a rfcsign.ngd file. 

• Executable :executable name 

A program block can be defined with or without the 
Executable construct. The Executable construct is useful 
when you want to define multiple option blocks for the same 
program. 

Case 1: 

If a program is defined with the Executable construct, 
XFLOW uses the executable name to build the program's 
command line. The program's option block in the option file 
has the same program, name. The program name masks the 
executable name so that you can define multiple option 
blocks for the same program allowing you to control which 
programs are executed 

For example, if you want to run TRCE. once after MAP and 
then again after PAR. The program name can be given any 
name you want. Within the block, the Executable construct 
will specify the correct name of the program. When XFLOW 
builds the command line for the program, it uses the name 
specified within the Executable construct. When you define 
the options for TRCE in the option file, there will be two 
entries and XFLOW will choose the correct one. 
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Example: 

Program post map tree 
Flag: ENABLED 
Executable: tree 
input : designjtuip.ncd 
Exports: design.twx 
End Program post map tree 

Case 2: 

If a program block is defined without the Exeeutable 
construct, XFLOVV uses the program ...name to build the 
command line 

• Export s : exported, filesjist 

List of program output files to copy into ExportDir 

• Reports: listof report Jiles 

List of program generated report files to copy into ReportDir 

• Variable Assignments $vnriable_name*zvilue; 

Variable assignments ean be used in the option files. During 
runtime, variables are substituted with their assigned values. 
You can use variables to specify the base name for the reports 
and program input or output files. The base name for 
functional simulation is func sim. The base name for timing 
simulation is time sim. Defined variables have global scope. 

• End Program program name 

Tire last line of a Program block is End Program. 

• User command block 

You can use this block to run programs or scripts between Xilinx 
programs. For example, if you want to run a script after map, you 
can add a User Command Block in the fpga.flw file as follows. 

UscrConmand 

Cndlino: "myscrIpt.cih” 

End Ur.crCcmn.jnd 

Following are some more examples of User Command Blocks: 
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UserConmand 

Cndlmc: "printenv"; 

End UserCcmnand 

UserConmand 

Cndlinc:" Is -ltr"; 

End UserCcmnand 

UserConmand 

Cndlinc:" Is -1 calc.nqc"; ♦ This works if calc.ngo 

^exists. 

9 If calc.ngo docs not exist, 
t the Is ccmnand will 
9 return a non zero 
9 to xfiow and xflcw will 
9 end and give an 
9 error message. 

End UserCcmnand 

UserConmand 

Cndlinc:"/home/test/xflow/userscript.csh"; 

End UserCcmnand 

Following are some examples of User Command Blocks that do not 
work. 


UserConmand 

Cndlinc:"Is -1 *.ngc"; I doesn't handle tho 
End UserCcmnand 


UserConmand 

Cndlinc:"/bin/rm -rf SMYVAR/calc.ngo"; 
* doesn't handle the 
End UserCcmnand 


UserConmand 

Cndlmc:" i f ( -e *.ngo ) /bin/rn -rf # .ngo"; 
9 doesn't hamdlc the • (" 

End UserCcmnand 
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Flow File Example 

Following is an example fpga.flw file. For the most up-to-date 
version of the file, see the file located in SXILINX/xilinx/data. 

44*44*4*44*4*44*4*44*4444*4444*4444*44*4444*4444*444 

4 4 FileNamc: fpga.flw 

## 

44 Flow File to run Xilinx FPGA Flow 
44 Version: 1.0.0 

4 4 $HcaOcr: /devl/xcs /repo/onv/Jobs /Xf lovc/data/ f1owfiles/Attic/fpga. f 1 w, v 
1.1.2.2 1999/02/28 23:4* lyr Exp $ 

44*44*4*44*4*44*4*44*4444*4444*4444*44*4444*4444*4444* 

ExportDir: <workdir>; 4 Directory to copy program outputs 

ReportDir: <workdir>; 4 Directory to copy program reports 

4 

4 Flow Into for Translator 

4 

Progran ngdbuild 
Flag : ENABLED; 

Exports : <dcsign>.ngd; 

Reports : <dcsign>.bid; 

End Program ngdbuild 

4 

4 Flew Info for Mapper 

4 

Progran map 
Flag: ENABLED; 

Input: <dcsign>.ngd; 

Exports : <dcsagn>_map.ned; 

Reports : <dcsign>_iThap.mrp; 

End Program map 

4 

4 Flow Info for Post Map Trace 

4 

Progran pcst_map_trcc 
Flag: DISABLED; 

Executable: tree; 

Input: <dcsign>_nap.ncd; 

Reports: <design>.tver; 

End Program post._map_.trce 
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4 

4 Flow Into for Place and Route 

4 

Progran par 
Flag : ENABLED; 

Input: <dcsign>_nap.ncd; 

Exports : <dcsign>.ned; 

Reports: <design>.par <design>.dly, <dcsign>.pad; 

End Program par 

4 

4 Flow Info for Post Par Trace 

4 

Progran pcst_par — tree 
Flag: ENABLED; 

Executable: tree; 

Input: <dcsign>.ned; 

Reports: <design>.twr; 

End Program pist_par__tree 

4 

4 Flow Info for Annotator 

4 

Progran ngdanno 
Flag: ENABLED; 

Input: <design>.ned; 

End Program ngdanno 

4 

4 Flow Info for EDIF Notlist Writer 

4 

Progran ngd2cdif 
Flag: ENABLED; 

Input: <design>.nga; 

$input_extension = nga; 

$sinulation_output = time.sim; 

Exports: $s imulat ion_output .cdn Ssimulat ion_output. xrrm; 
End Program ngd2edif 

4 

4 Flow Info for Vcnlog Nctlist Writer 

4 

Progran ngd2vcr 
Flag: ENABLED; 

Input: ^design>.nga; 


DtTvfo/wte’iJ/ Reference Guide 


22-25 




Development System Reference Guide 


$input_cxtcnsicn = nge; 

$sinulAtion_output = timc.simj 

Exports: $simulation_output.v $simulAtion__cutput.sdf, 

SsinulAticn_output. tv, $sinu 1 Aticn__output .pin; 

End ProgrAm ngd2vcr 

4 

* Flow Into for VHDL Netlist Kritcr 

4 

Progran ngd2vhdl 
Flag: ENABLED; 

Input: <dcsign>.nga; 

$input_cxtcnsicn - ngA; 

$sinulAtion_output = time.simj 

Exports: $simulation_output.vhd $simulAtion_output.sdf, 

Ssinul At icr.__output. tvhd, $simulAt ion_output .pin; 

End ProgrAm ngd2vhdl 

4 

4 Flow Info for Bitgcn 

4 

ProgrAii bitgcn 
Flog: ENABLED; 

Input: <dcsign>.ned; 

Exports: <design>.bit, <dcsign>.ll, <design>.msx, <dcsign>.rbt; 

Reports: <design>.bgn, <dcsign>.drc; 

End ProgrAm bitgcn 

4 

Output Files 

Output files from XFLOW may be generated for the following: 

• FPGA programming data 

• CPLD programming data 

• Annotated netlist data—These files are only generated if you run 
the timing simulation flows 

• Timing simulation data—These files are only generated if you 
run the timing simulation flows. They are the primary output of 
the back-annotation process. 

• Functional simulation data—These files are only generated if you 
run the functional simulation flows. 
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• Guide data 

• Reports 

The following tables illustrate specific files that are generated for each 
type. 

Table 22-6 FPGA Programming Data 


Rle Type 

Syntax 

Location 

Bitstream 

design .bit 

Current working directory 

Export directory 

LL file 

mm 

Current working directory 

Export directory 

Rawbits file 

design, rbt 

Current working directory 

Export directory 


The desigitM file is generated if the -1 option is set for bitgen in the 
option file. 


Tine design.ibf file is created if the -b option is set for bitgen in the 
option file. 

Table 22-7 CPLD Programming Data 


Rle Type 

Syntax 

Locations 

JEDEC file 

design jed 

Current working directoty 

Export directory’ 

Design file 

design.vm6 

Current working directory 

Export directory 


Note that VM6 files from the M1.5 release cannot be used as inputs to 
2.1i downstream processes. You must rerun the fitter using the 2.1i 
software to create a new VM6 file before performing any of the 
following tasks: 

• Creating a JEDEC programming file (.jed file from the hprep 
program 

• Creating a timing report (.tim file from the taengine) 

• Running the Timing Analyzer 

• Creating a timing simulation model (.nga file from the tsim 
program) for input to NGD2EDIF, NCD2VHDL, or NGD2VER. 
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Table 22-8 Annotated Netlist Data 


File Type 

Syntax 

Location 

ED1F netlist 

time sim.edn 

Current working directory 
Export directory 

XNF netlist 

time.sim.xnf 

Current working directory 
Export directory 

XMM file 

time, sim.xmm 

Current working directory 
Export directory 


Annotated netlist files are only generated if you run timing 
simulation flows. 


Table 22-9 Functional Simulation Data 


File Type 

Syntax 

Location 

ED1F simulation file 

func sim.edif 

Current working 
directory 

Export directory 

Verilog simulation file 

func>im.v 

Current working 
directory 

Export directory 

Verilog test vector file 

func sim.tv 

Current working 
directory 

Export directory 

VHDL simulation file 

func.sim.vhd 

Current working 
directory 

Export directory 

VHDL test vector file 

func sim.tvhd 

Current working 
directory 

Export directory 
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Table 22-10 Timing Simulation Data 


File Type 

Syntax 

Location 

ED1F simulation file 

time sim.edn 

Current working 
directory 

Export directory 

Veil log simulation file 

wm 

Current working 
directory 

Export directory 

Verilog test vector file 

time_sim.lv 

Current working 
directory 

Export directory 

VHDL simulation file 

time_sim.vhd 

Current working 
directory 

Export directory 

VHDL test vector file 

time sim.tvhd 

Current working 
directory 

Export directory 

SDF simulation file 

time sim.sdf 

Current working 
directoiy 

Export directory 


Timing simulation data tiles are only generated if you run timing 
simulation flows. These files are the primary output of back- 
annotation. 

Table 22-11 Guide Data 


File Type 

Syntax 

Location 

FPGA guide file 

*.ncd 

Current working directory 
Export directory 

CPLD guide file 

*-gyd 

Current working directoiy 
Export directory 
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Table 22-12 Applicalion Data Files 


File Type 

Syntax 

Location 

XFLOW log file 

xflow.log 

Current working directory 

XFLOW script file 

xflow.scr 

Current working directory 
Export directory 


XFLOVV generates various reports depending on which command 
line options are used. Tire following tables indicate the types of 
generated reports. 

Table 22-13 FPGA Report Files 


Report 

Flow Type 

Location 

Translation Report 
(design.bid) 


Current Working Directory 
Report Directoiy 

Mapping 
(design _ map. mip) 


Current Working Directory 
Report Directory 

Logic Level Timing 
(design map.lwi) 


Current Working Directory 
Report Directoiy 

Place and Route 
(design.par) 

-implement 

Current Working Directory 
Report Directoiy 

Pad 

fdtsijyi.pad) 


Current Working Directory 
Report Directory 

Asynchronous Delay 
(dcsijj/t.dlv) 


Current Working Directory 
Report Directoiy 

Post Layout Timing 
(design.iwi) 


Current Working Directory 
Report Directoiy 

BitGen 
(design.bg\) 

-config 

Current working directoiy 
Report directory 
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Table 22-14 CPLD Report Files 


Report 

Flow Type 

Location 

Translation 

(A-si^/t.bld) 

-fit 

Current Working Directory 
Report Directory 

Fitting 

(rfesigtt.rpt) 

Current Working Directory 
Report Directory 

Post Layout Timing 
(ifi’s/y/Mim) 

Current Working Directory 
Report Directory 
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Appendix A 


Xilinx Development System Files 


This appendix gives an alphabetic listing of the files used by the 
Xilinx Development System. 


Name 

Type 

Produced By 

Description 

ALF 

ASCII 

NGDAnno 

A report file containing information 
about an NGDAnno run. 

BIT 

Data 

BitCien 

Download bitstream file for devices 
containing all of the configuration 
information from the NCD file. 

BGN 

ASCII 

BitGen 

A report file containing information 
about a BitGen run. 

BLD 

ASCII 

NGDBuild 

A report file containing information 
about an NGDBuild run, including 
the subprocesses run by NGDBuild. 

DATA 

C File 

TRCE 

File created with the -stamp option to 
TRCE that contains timing model 
information. 

DC 

ASCII 

Synopsys FPGA 
Compiler 

Synopsys setup file containing 
constraints read into the Xilinx 
Development System. 

DLY 

ASCII 

PAR 

Contains delay information for each 
net in a design. 

DRC 

ASCII 

BitGen 

A DRC runs and the DRC file is 
produced unless you enter a -d 
option on the BitGen command line 

ED1F (various 
file extensions) 

ASCII 

CAE vendor's EDIF 2 

0 0 netlist writer. 

EDIF netlist. The Xilinx Development 
System accepts an EDIF 20 0 Level 0 
netlist file. 
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Name 

Type 

Produced By 

Description 

EDN 

ASCI! 

NGD2EDIF 

Default extension for an EDIF 

2 0 0 netILst file. 

EPL 

ASCI! 

FPGA Editor 

FPGA Editor command log file. The 
EPL file keeps a record of all FPGA 
Editor commands executed and 
output generated. It is used to 
recover an aborted FPGA Editor 
session. 

EXO 

Data 

PROMGen 

PROM file in Motorola’s EXORMAT 
format. 

FLW 

ASCII 

Provided with soft¬ 
ware 

Contains command sequences for 
XFLOW programs. 

fpga editor.ini 

ASCI! 

Xilinx software 

Script that determines what FPGA 
Editor commands are performed 
when the FPGA Editor starts up. 

fpga_editor_ 

userini 

ASCII 

Xilinx software 

A supplement to the fpga editor.ini 
file used for modifying or adding to 
the fpga editor.ini file. 

GYD 

ASCII 

CPLD fitter 

CPLD guide file 

HEX 

Hex 

PROMGen Command 

Output file from PROMGEN that 
contains a hexadecimal representa¬ 
tion of a bitstream. 

1TR 

ASCII 

PAR 

Intermediate failing timespec 
summary from routing 

JED 

JEDEC 

CPLD fitter 

Programming file to be downloaded 
to a device 

LOG 

ASCII 

NGD2VER 

NGD2VHDL 

A log file containing all the messages 
generated during the execution of 
NGD2VER (ngd2ver.log) or 
NGD2VHDL (ngd2vhdl.log). 

LCA 

ASCI! 

Xilinx Development 
System 

A mapped file of an earlier release 
Xilinx design. 

L2N 

ASCII 

LCA2NCD 

A report file containing information 
about an LCA2NCD run. 
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Name 

Type 

Produced By 

Description 

LL 

ASCII 

BitGen 

An optional ASCII logic allocation 
file with an .11 extension. The logic 
allocation file indicates the bitstream 
position of latches, flip-flops, and 

IOB inputs and outputs. 

MEM 

ASCII 

User (with text editor) 
LogiBLOX 

User-edited memory file that defines 
the contents of a ROM. 

MCS 

Data 

PROMGen 

PROM-formatted file in Intel's MCS- 
86 format. 

MDF 

ASCII 

MAP or LCA2NCD 

A file describing how logic was 
decomposed when the design was 
mapped. The MDF file is used for 
guided mapping. 

MFP 

ASCII 

Floorplanner 

Map Floorplanner File, which is 
generated by the Floorplanner. speci¬ 
fied as an input file with the -fp 
option. The MFP file is essentially 
used as a guide file for mapping. 

MRP 

ASCII 

MAP 

MAP report file containing informa¬ 
tion about a technology mapper 
command run. 

MSK 

Data 

BitGen 

This file is used to compare relevant 
bit locations when reading back 
configuration data contained in an 
operating Xilinx device. 

MOD 

ASCII 

TRCE 

File created with the -stamp option to 
TRCE that contains timing model 
information. 

NCD 

Data 

Mappers, ECA2NCD, 
PAR, FPGA Editor 

A flat physical design database corre¬ 
lated to the physical side of the NGD 
in order to provide coupling back to 
the user s original design. 

NCF 

ASCII 

CAE Vendor toolset 

Vendor-specified logical constraints 
files. 

NGA 

Data 

NC.DAnno 

Back-annotated mapped NCD file. 
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Name 

Type 

Produced By 

Description 

NGC 

Binary 

LogiBLOX 

A file containing the implementation 
of a module in the design. 

NGD 

Data 

NGDBuild 

Generic Database file. This file 
contains a logical description of the 
design expressed both in terms of the 
hierarchy used when the design was 
first created and in terms of lower- 
level Xilinx primitives to which the 
hierarchy resolves. 

NGM 

Data 

MAP 

A file containing all of the data in the 
input NGD file as well as informa¬ 
tion on the physical design produced 
by the mapping. The NGM file is 
used for back-annotation. 

NGO 

Data 

Netlisl Readers 

A file containing a logical description 
of the design in terms of its original 
components and hierarchy. 

NMC 

Binary 

FPGA Editor 

Xilinx physical macro library file. 
Contains a physical macro definition 
Hut can be instantiated into a design. 

OPT 

Text 

Input file option 

Option file used by XFLOW. 

PAD 

ASCII 

PAR 

A file containing a listing of all 

I/O components used in the design 
and their associated primary pins. 

PAR 

ASCII 

PAR 

A PAR mport file containing execu¬ 
tion information about the PAR 
command run. The file shows the 
steps taken as the program converges 
on a placement and routing solution. 

PCF 

ASCII 

MAP, FPGA Editor 

A file containing physical constraints 
specified during design entry (that is, 
schematics) and constraints added by 
the user. 

PRM 

ASCII 

PROMGen 

A file containing a memory map of a 
PROM file showing the starting and 
ending PROM address for each BIT 
file loaded. 
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Name 

Type 

Produced By 

Description 

RBT 

ASCI! 

BitGen 

A "rawbits' file consisting of ASCII 
ones and zeros representing the data 
in the bitstream file. 

RPT 

ASCII 

PIN2UCF 

If PIN2UCF discovers conflicting 
constraints, it writes information to a 
report file, named pinlodcrpt. 

RCV 

ASCII 

FPGA Editor 

FPGA Editor recovery file. 

SCR 

ASCI! 

FPGA Editor or 

XFLOW 

FPGA Editor or XFLOW command 
script file. 

SDF 

ASCI! 

NC.D2VER, 

NGD2VHDL 

Contains the timing data for a 
design. Standard Delay Format File. 

TDR 

ASCI! 

DRC 

Physical DRC report file. 

TEK 

Data 

PROMGen 

PROM-formatted file in Tektronix’s 
TEKHEX format. 

TV 

ASCI! 

NGD2VER 

Verilog test fixture file. 

TV'HD 

ASCI! 

NC.D2VHDL 

VHDL testbench file. 

TVVR 

ASCI! 

TRACE 

A liming report file ptxxiuced by 
TRACE. 

UCF 

ASCI! 

User (with text editor) 

User-specified logical constraints 
files. 

V 

ASCII 

NGD2VER 

Verilog netlist. 

VHD 

ASCII 

NC.D2VHDL 

VHDL netlLst. 

VM6 

Design 

CPLD Fitter 

Output file from fitter 

XMM 

ASCII 

NGD2ED1F 

Defines the initial contents of the 
RAMs in the design for a simulator 

XNF 

ASCII 

Previous releases o! 
Xilinx Development 
System. CAE vendor 
toolsets 

Xilinx netlist format file. 

XTF 

ASCII 

Previous releases ol 
Xilinx Development 
System 

Xilinx netlist format file. 

XPI 

ASCII 

PAR 

Contains PAR run summary. 
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Appendix B 


EDIF2NGD, XNF2NGD, and NGDBuild _ 

This appendix describes the nellisl reader programs, EDIF2NGD and 
XNF2NGD. and how these programs interact with NGDBuild. The 
appendix contains the following sections. 

• "EDIF2NGD" 

• "XNF2NGD” 

• "NGDBuild" 

• "Nellister Launcher" 

• "File Names and Locations" 

EDIF2NGD 

This program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• Spartan2 

• Spartan XL 

• Virtex 

• XC9500 

• XC9500XL 
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Tine EDIF2NGD program allows you to read an EDIF (Electronic 
Design Interchange Format) 2 0 0 file into the Xilinx Development 
System toolset. EDIF2NGD converts an industry-standard EDIF 
netlist to an NGO file—a Xilinx-specific format. Tine EDIF file 
includes the hierarchy of the input schematic. The output NGO file is 
a binary database describing the design in terms of the components 
and hierarchy specified in the input design file. Tine following figure 
shows the flow through EDIF2NGD. 


Schematic 

Drawing 


Synthesis 
Vendor Tools 


EDIF 2 0 0 Netlist 


CAE VENDOR 
TOOLS 


XILINX 

DEVELOPMENT 

SYSTEM 


X6994 


Figure B-1 EDIF2NGD Design Flow 

The NGO file can be converted to an NGD file using the NGDBuild 
program. The NGD file can be mapped into an NCD file, which can 
then be placed and routed. 

The input file must be a Level 0 EDIF netlist, as defined in the EDIF 2 
0 0 specification. The Xilinx Development System toolset can 
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understand EDIF files developed using components from any of 
these libraries. 

• Xilinx Unified Libraries (described in the Libraries Guide) 

• XS1 (Xilinx Synopsys Interface) Libraries 

• Any Xilinx physical macros you create 

Note: Xilinx tools do not recognize Xilinx Unified Libraries 
components defined as macros; they only recognize the primitives 
from this library. The third-party EDIF writer must include 
definitions for all macros. 

You can run EDIF2NGD in the following ways. 

• From the Design Manager/Flow Engine during the Translate 
process 

• Automatically from NGDBuild 

• From the UNIX or DOS command line, as described in the 
following sections 

Note: When creating nets or symbols names, do not use reserved 
names. Reserved names are the names of symbols for primitives and 
macros in the Libraries Guide and net names GSR. RESET, GR. and 
PRELOAD. If you used these names, EDIF2NGD issues an error. 

EDIF2NGD Syntax 

Tire following command reads your EDIF netlist and converts it to an 
NGO file. 

edif 2 ngd [o/'fw/rs) edif file ngo_file 

Options can be any number of the ED1F2NGD options listed in the 
"ED1F2NGD Options" section. They do not need to be listed in any 
particular order. Separate multiple options with spaces. 

Edif file is the EDIF 2 00 input file to be converted. The file must have 
an extension. If the file lias an extension other than .edn, you must 
enter the extension as part of edif file. If you enter a file name with no 
extension, ED1F2NGD looks for a file with an .edn extension and the 
name you specified. 

Note: For EDIF2NGD to read a Mentor Graphics EDIF file, you must 
have installed the Mentor Graphics software component on your 
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system. Similarly, to read a Cadence HD1F file, you must have 
installed the Cadence software component. 

Ngo/ile is the output file in NGO format. The output file name, its 
extension, and its location are determined in this way. 

• If you do not specify an output file name, the output file has the 
same name as the input file, with an .ngo extension. 

• If you specify an output file name with no extension. ED1F2NGD 
appends the .ngo extension to the file name. 

• If you specify a file name with an extension other than .ngo, you 
get an error message and EDIP2NGD does not run. 

• If you do not specify a full pathname, the output file is placed in 
the directory from which you ran EDIF2NGD. 

If the output file exists, it is overwritten with the new file. 

EDIF2NGD Files 

This section describes the ED1F2NGD input and output files. 

Input Files 

EDIF2NGD uses the following files as inputs. 

• ED1F file—ED1F 2 00 netlist file. The file must be a Level 0 F.D1F 
netlist. as defined in the ED1F 2 0 0 specification. 

• NCF file—Netlist Constraints File. Produced by a vendor toolset, 
this file contains constraints specified within the toolset. 
ED1F2NCD reads the constraints in this file and adds the 
constraints to the output NGO file. 

EDIF2NGD mads the constraints in the NCF file if the NCF file 
has the same base name as the input ED1F file and an .ncf exten¬ 
sion. The name of the NCF file does not have to be entered on the 
EDIF2NCD command line. 

Output Files 

Tlie output of EDIF2NCD is an NGO file—a binary file containing a 
logical description of the design in terms of its original components 
and hierarchy. 
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EDIF2NGD Options 

This section describes the EDIF2NGD command options. 

-a (Add PADs to Top-Level Port Signals) 

Tine -a option adds PAD properties to all top level port signals. This 
option is necessary if the EDIF2NGD input is an EDIF file in which 
PAD symbols were translated into ports. If you do not specify a -a 
option for one of these EDIF files, the absence of PAD instances in the 
EDIF file causes EDIF2NGD to mad the design incorrectly. Subse¬ 
quently, MAP interprets the logic as unused and removes it. 

In all Mentor Graphics and Cadence EDIF files PAD symbols are 
translated into ports. For EDIF files from either of these vendors, the 
-a option is set automatically; you do not have to enter the -a option 
on the EDIF2NGD command line. 

-f (Execute Commands File) 

-f command, file 

Tine -f option executes the command line arguments in the specified 
command_file. For more information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 

-I (Libraries to Search) 

-1 libname 

Tine -1 option specifies a libraiy to search when determining what 
library components were used to build the design. This information 
is necessary for NGDBuild, which must determine the source of the 
design’s components before it can resolve the components to Xilinx 
primitives. 

You may specify multiple -I options on the command line. Each must 
be preceded with - 1 ; you cannot combine multiple libname specifiers 
after one -I. For example, -1 xilinxun synopays is not acceptable, 
while -1 xilinxun -1 aynopays is acceptable. 

Tire allowable entries for libname are the following. 

xilinxun (For Xilinx Unified library) 

aynopaya 
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Note: You do not have to enter xilinxun with a -1 option. The Xilinx 
Development System tools automatically access these libraries. You 
do not have to enter synopsys with a -1 option il the ED1F netlist 
contains an author construct with the string "Synopsys." In this case, 
EDIF2NGD automatically detects that the design is from Synopsys. 

-p (Part Name) 

-p /Mil 

Tine -p option specifies the part into which your design is 
implemented. The -p option can specify an architecture only, a 
complete part specification (device, package, and speed), or a partial 
specification (for example, device and package only). 

Tine syntax for the -p option is described in the "Part Numbers in 
Commands" section of the "Introduction" chapter. Examples of /xirt 
entries are XC3100A. XC4003E-PC84, and XC4028EX-HQ240-3. 

If you do not specify a part when you run EDIF2NGD, you will have 
to specify one when you run NGDBuild. 

You can also use the -p option to override a part name in the input 
ED1F netlist or a part name in an NCF file. 

-r (Ignore LOC Properties) 

The -r option filters out all location properties (LOC=) from the 
design. This option can be used when you am migrating to a different 
device or architecture, because locations in one architecture do not 
match locations in another. 
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XNF2NGD 

Tliis program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC40G0EX/XL/XV/XLA 

• XC5200 

• Spartan 

• SpartanZ 

• SpartanXL 

• XC9500 

• XC9500XL 

Note: XNF primitives are not defined for the Virtex architecture, and 
XNF files created for Virtex am rejected by XNF2NGD. However, if 
you have XNF netlists that were created for the XC3000, XC4000E. or 
XC5200 architectures, you can include these XNF netlists in a design 
that you target to a Virtex device. 

XNF2NGD allows you to read a Version 6.1 XNF (Xilinx Netlist 
Format) file into the Xilinx Development System toolset. XNF2NGD 
converts an XNF file to an NGO file, which is a binary database 
describing the netlist in terms of Xilinx components. After you 
convert the XNF file to an NGO file, you run NGDBuild to create an 
NGD file, which expands the design to include a description reduced 
to Xilinx primitives. The following figure shows the flow through 
XNF2NGD. 
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Figure B-2 XNF2NGD Design Flow 

You can run XNF2NGD in the following ways. 

• From the Design Manager/Flow Engine during the Translale 
process 

• Automatically from NGDBuild 

• From the UNIX or DOS command line, as described in the 
following sections. 

Note: When creating nets or symbols names, do not use reserved 
names. Reserved names are the names of symbols for primitives and 
macros in the Libraries Guide and net names GSR.RESET. GR. and 
PRELOAD. If you used these names, XNF2NGD Issues an error. 
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XNF2NGD Syntax 

Tlie following command reads your XNF netlist and converts il lo an 
NGO file. 

xnf 2 ngd [options] xnfjile ngo. file 

Options can be any number of Ihe XNF2NGD options listed in the 
"XNF2NGD Options” section. They do not need to be listed in any 
particular order. Separate multiple options with spaces. 

Xnf Jilt is the input file (in XNF format) to be converted. The file can 
have any extensions (for example, .xnf, .xtf. .xff. .xg, or .sxnf), as long 
as the file is in XNF format. If you enter a file name with no extension. 
XNF2NGD looks for a file with an .xnf extension and the name you 
specified. 

Ngojite is the output file in NGO format. The output file name, its 
extension, and its location are determined in this way. 

• If you do not specify an output file name, the output file has the 
same name as the input file, with an .ngo extension. 

• If you specify an output file name with no extension, XNF2NGD 
appends the .ngo extension to the file name. 

• If you specify a file name with an extension other than .ngo, you 
get an error message and XNF2NGD does not run. 

• If you do not specify a full pathname, the output file is placed in 
the directory from which you ran XNF2NGD. 

If the output file already exists, it is overwritten with the new file. 
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XNF2NGD Files 

This section describes the XNF2NC.D input and output files. 

Input Files 

XNF2NGD uses the following files as inputs. 

• XNF file—Xilinx Netlist Format (XNF) text file. The file can have 
any extension as long as the contents are in XNF format. 

• NCF file—Netlist Constraints File. Produced by a vendor toolset, 
this file contains constraints specified within the toolset. 
XNF2NGD reads the constraints in this file and adds the 
constraints to the output NC.O file. 

XNF2NGD reads the constraints in the NCF file if the NCF file 
has the same name as the input XNF file and an extension of .net. 
The name of the NCF file does not have to be entered on the 
XNF2NGD command line. 

Output Files 

The output of XNF2NGD is an NC.O file—a binary file containing a 
logical description of the design in terms of its original components 
and hierarchy. 

XNF2NGD Options 

This section describes the XNF2NGD command options. 

-f (Execute Commands File) 

-f commandjile 

The -f option executes the command line arguments in the specified 
command, file. For mom information on the -f option, see the "-f 
Option" section of the "Introduction" chapter. 
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(Libraries to Search) 

-1 libname 

The -I option indicates the list of libraries to search when 
determining what library components were used to build the design. 
Tills information is necessary for NGDBuild. which must determine 
the source of the design's components before it can resolve the 
components to Xilinx primitives. 

You can specify multiple -1 options on the command line. Each must 
be preceded with - 1 ; you cannot combine multiple libname specifiers 
after one -I. For example, -1 xilinxun synopsys is not accept¬ 
able, while -1 xilinxun -1 synopsys is acceptable. 

The allowable entries for libname are the following. 

xilinxun (For Xilinx Unified library) 

synopsys 

XC3000 

XC4000 

XC9500 

Note: You do not have to enter xilinxun with a -1 option. The Xilinx 
Development System tools automatically access these libraries. In 
most cases, you do not have to enter XC3000 or XC4000 with a -1 
option. However, if your XNF file contains an input latch (INLAT) 
component and no part type is specified in the XNF file, the meaning 
of the 1NLATcomponent Ls ambiguous. In this case, XNF2NGD will 
stop with an error message. You must run XNF2NGD again using the 
-1 option to define the 1NLAT component; -1 XC3000 means the 
1NLAT Ls transparent High and -1 XC4000 means it is transparent 
Low. 

-p (Part Name) 

-p pari 

The -p option specifies the part into which your design is 
implemented. The -p option can specify an architecture only, a 
complete part specification (device, package, and speed), or a partial 
specification (for example, device and package only). 


Development System Reference Guide 


B-11 




Development System Reference Guide 


Tine syntax lor the -p option is described in the "Part Numbers in 
Commands" section of the "Introduction" chapter. Examples of port 
entries are XC3100A. XC4003E-PC84. and XC4028EX-HQ240-3. 

If you do not specify a part when you run XNF2NGD, you will have 
to specify one when you run NGDBuild. 

You may also use the -p option to override a part name in the input 
XNF netlist or a part name in an NCF file. 

-r (Ignore LOC Properties) 

Tine -r option filters out all location properties (LOC=) from the 
design. This can be used when you am migrating to a different device 
or architecture, because locations in one architecture do not match 
locations in another. 

-u (Top-Level XNF Netlist) 

The -u option specifies that the input XNF file is the top-level design 
netlist. When XNF2NGD translates netlists at lower hierarchical 
levels, XNF2NGD adds to the lower-level NGO file information that 
is unnecessary in the top-level NGO file. The -u option prevents this 
information from being added to the top-level NGO file. 
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NGDBuild 

Tills program is compatible with the following families. 

• XC3000A/L 

• XC3100A/L 

• XC4000E/L 

• XC4000EX/XL/XV/XLA 

• XC5200 

• Spartan 

• SpartanZ 

• SpartanXL 

• Vrrtex 

• XC9500 

• XC9500XL 

NGDBuild performs all the steps necessary to read a netlist file in 
XNF or ED1F format and create an NGD file describing the logical 
design. The NGD file resulting from an NGDBuild run contains both 
a logical description of the design reduced to NGD primitives and a 
description in terms of the original hierarchy expressed in the input 
netlist. The output NGD file can be mapped to the desired device 
family. 

Converting a Netlist to an NGD File 

NGDBuild performs the following steps to convert a netlist to an 
NGD file. This flow is shown in the following figure. 
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Figure B-3 NGDBuild and the Nellis! Readers 

1. Roads Ihe source nellisl. 

To perform this step, NGDBuild invokes Ihe Netlister Launcher, 
a pari of Ihe NGDBuild software which determines the type of 
the input netlist and starts the appropriate netlist reader 
program. If the input netlist is in EDIF or XNF format, the 
Netlister Launcher invokes EDIF2NGD or XNF2NGD. If the 
input netlist is in another format that the Netlister Launcher 
recognizes, the Netlister Launcher invokes Ihe program neces¬ 
sary to convert the netlist to EDIF or XNF format, then invokes 
EDIF2NGD or XNF2NGD. The netlist reader produces an NGO 
file for the top-level netILst file. 
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If any subfiles are referenced in Hie top-level netILst (for example, 
a PAL description file, or another schematic file), the Netlister 
Launcher invokes the appropriate netlist reader for each of these 
files to convert each referenced file to an NGO file. 

The Netlister Launcher is described in the "Netlister Launcher" 
section. Tine netlist reader programs are described in the 
"EDIF2NCD" section and the "XNF2NGD" section. 

2. Reduces all components in the design to NGD primitives. 

To perform this step, NGDBuild merges components that 
reference other files by finding the referenced NGO files. 
NGDBuild also finds the appropriate system library components, 
physical macros (NMC files) and behavioral models. 

3. Checks the design by running a Logical DRC (Design Rule 
Check) on the converted design. 

Tile Logical DRC is a series of tests on the logical design. It is 
described in "The Logical Design Rule Check" chapter. 

4. Writes an NGD file as output. 

When NGDBuild reads the source netlist. it detects any files or parts 
of the design that have changed since the last run of NGDBuild. It 
updates files as follows. 

• If you have modified your input design since you last ran 
NGDBuild, NGDBuild updates all of the files affected by the 
change and use the updated files to produce a new NGD file. 

Tine Netlister Launcher checks timestamps (date and time infor¬ 
mation) for netlist files and intermediate NGDBuild files (NGOs). 
If an NGO file has a timestamp earlier than the netlist file that 
pinduced it. the NGO file Ls updated and a new NGD file is 
produced. 

• NGDBuild completes the NGD production if all or some of the 
intermediate files already exist. These files may exist if you ran a 
netlist reader before you ran NGDBuild. NGDBuild uses the 
existing files and create the remaining files necessary to produce 
the output NGD file. 

Note: If the NGO for an netlist file is up to date. NGDBuild looks for 
an NCF file with the same base name as the netlist in the netlist direc¬ 
tory and compares the timestamp of the NCF file against that of the 
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NGO file. If the NCF file is newer, XNF2NGD or ED1F2NGD is run 
again. However, if an NCF file existed on a previous run of 
NGDBuild and the NCF file was deleted, NGDBuild will not detect 
that XNF2NC.D or EDIF2NGD must be run again. In this case, you 
must use the -nt on option to force a rebuild. 

Syntax, files, and options for the NGDBuild command arc described 
in the "NGDBuild" chapter. 

Bus Matching 

When NGDBuild encounters an instance of one netlist within another 
netlist. it requites that each pin specified on the upper-level instance 
match to a pin (or port) on the lower-level netlist. Two pins must 
have exactly the same name in order to be matched. This requirement 
applies to all FPGAs and CPLDs supported for NGDBuild. 

If the interface between the two netlists uses bused pins, these pins 
arc expanded into scalar pins before any pin matching occurs. For 
example, the pin A|7:0| might be expanded into 8 pins namedA[7| 
through A|0). If both netlists use the same nomenclature (that is. the 
same index delimiter characters) when expanding the bused pin. the 
scalar pin names will match exactly. However, if the two netlists were 
created by different vendors and different delimiters arc used, the 
resulting scalar pin names do not match exactly. 

In cases where the scalar pin names do not match exactly. NGDBuild 
analyzes the pin names in both netlists and attempts to identify 
names that resulted from the expansion of bused pins. When it iden¬ 
tifies a bus-expanded pin name, it tries several other bus-naming 
conventions to find a match in the other netlist so it can merge the 
two netlists. For example, if it finds a pin named A<3) in one netlist. it 
looks for pins named A(3), A|3], A<3> or A3 in the other netlist. 

Following are the bus naming conventions understood by 
NGDBuild. 


Naming Convention 

Example 

busnmie(index) 

DI(3) 

busname<index> 

DI<3> 

busimme\index] 

D1I3] 

busiutmeindex 

D13 
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If your third-party netlist writer allows you to specify the bus¬ 
naming convention, use one of the conventions shown in the 
preceding table to avoid "pin mismatch" errors during NGDBuild. If 
your third-party ED1F writer preserves bus pins using the EDIF 
"array" construct, the bus pins will be expanded by EDIF2NGD 
using parentheses, which is one of the supported naming conven¬ 
tions. 

Note: NGDBuild support for bused pins is limited to this under¬ 
standing of different naming conventions. It is not able to merge 
together two netlists if a bused pin has different indices between the 
two files. For example, it cannot match A|7:0| in one netlist to A( 15:81 
in another. 

In the Xilinx UnifiedPro library for Virtex, some of the pins on the 
block RAM primitives are bused. If your third-party netlist writer 
uses one of the bus naming conventions listed in the preceding table 
or uses the EDIF array construct, these primitives are recognized 
properly by NGDBuild. The use of any other naming convention may 
result in an "unexpanded block" error during NGDBuild. 

Netlister Launcher 

Tine Netlister Launcher, which is part of NGDBuild, performs any 
netlist translations necessary to execute the NGDBuild command. 

When NGDBuild is invoked, the Netlister launcher goes through the 
following steps. 

1. Tine Netlister Launcher initializes itself with a set of rules for 
determining what netlist reader to use with each type of netlist, 
and the options with which each reader is invoked. 

Tine rules are contained in the system rulis file (described in the 
"System Rules File" section) and in the user rules file (described 
in the "User Rules File" section). 

2. NGDBuild makes the directory of the top-level netlist the first 
entry in the Netlister Launcher's list of search paths. 

3. For the top-level design and for each file referenced in the top- 
level design, NGDBuild queries the Netlist Launcher for the pres¬ 
ence of the corresponding NGO file. 

4. For each NGO file requested, the Netlister Launcher performs 
these actions. 
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• Determines what netlist is the source for the requested NGO 
file. 

Tine Netlister Launcher determines the source netlist by 
looking in its rules database for the list of legal netlist exten¬ 
sions. 

Then, it looks in the search path (which includes the current 
directory) for a netlist file possessing a legal extension and 
the same name as the requested NGO file. 

• Finds the requested NGO file. 

Tine Netlister Launcher looks first in the directory specified 
with the -dd option (or current directory if a directory is not 
specified). If the NGO file is not found there and the source 
netlist was not found in the search path, the Netlister 
Launcher looks for the NGO file in the search path. 

• Determines whether the NGO file must be created or 
updated. 

If neither the netlist source file nor the NGO file is found, 
NGDBuild exits with an error. 

If the netlist source file is found but the corresponding NGO 
file is not found, the Netlister Launcher invokes the proper 
netlist reader to create the NGO file. 

If the netlist souree file is not found but the corresponding 
NGO file is found, the Netlister Launcher indicates to 
NGDBuild that the file exists and NGDBuild uses this NGO 
file. 

If both the netlist source file and the corresponding NGO file 
are found, the netlist file's time stamp is checked against the 
NGO file’s timestamp. If the timestamp of the NGO file is 
later than the source netlist, the Netlister Launcher returns a 
"found" status to NGDBuild. If the timestamp of the NGO 
file is earlier than the netlist souree, or the NGO file is not 
present in the expected location, then the Launcher creates 
the NGO file from the netlist source by invoking the netlist 
reader specified by its rules. 

Note: The timestamp check can be overridden by options on the 
NGDBuild command line. The -nt on option updates all existing 


B-fS 


Xilinx Development System 




EDIF2NGD, XNF2NGD, and NGDBuild 


NGO files, regardless of Iheir limeslamps. Tine -nt off option does not 
update any existing NGO files, regardless of their timestamps. 

5. Tine Netlister launcher indicates to NGDBuild that the requested 
NGO files have been found, and NGDBuild can process all of 
these NGO files. 

Netlister Launcher Rules Files 

Tine behavior of the Netlister Launcher is determined by rules 
defined in the system rules file and the user rule file. These rules 
determine the following. 

• What netlist source files am acceptable 

• Which netlist reader reads each of these netlist files 

• What the default options are for each netlist reader 

Tine system rules file contains the default rules supplied with the 
Xilinx Development System software. Tine user rules file can add to 
or override the system rules. 

Tine following sections describe the user rules file and the system 
rules. 

User Rules File 

Tine user rules file can add to or override the rules in the system rules 
file. You can specify the location of the user rules file with the -ur 
option to the NGDBuild command line. 

User Rules and System Rules 

User rules are treated as described below. 

• A user rule can override a system rule if it specifies the same 
source and target files as the system rule. 

• A user rule can supplement a system rule if its target file is iden¬ 
tical to a system rule's souree file, or if its source file is the same 
as a system rule's target file. 

• A user rule that has a source file identical to a system rule’s target 
file and a target file that is identical to the same system rule's 
source file is illegal, because it defines a loop. 
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User Rules Format 

Each rule in Ihe user rules file has Ihe following formal. 
KuleName = <nilenume]>; 

<Jcey2> - <iYtIue2>; 


<Jceyn> = <mluen>i 

Tire following is a description of Ihe keys allowed and Ihe values 

expected. 

Note: All of the values mentioned in the following paragraphs are 

described in Ihe "Value Types in Key Statements" section. 

• RuieHarse—This key identifies Ihe beginning of a rule. Il is also 
used in error messages relating to the rule. Il expects a RULE- 
NAME value. A value is required. 

• NetiistFile—This key specifies a netlist or class of netlists 
that the netlist leader takes as input. The extension of NetlislFile 
is used together with Ihe TargetExtension to identify the rule. It 
expects either a FILENAME or an EXTENSION value. If a file 
name is specified, it should be )ust a file name (that is, no path). 
Any leading path is ignoied. A value is required. 

• TargetExtension—This key specifies the class of files 
generated by the netlist reader It is used together with Ihe 
extension from NetlislFile to identify the rule. Il expects an 
EXTENSION value. A value is required. 

• tleti ister—This key specifies the netlist reader to use when 
translating a specific netlist or class of netlists to a taiget file. The 
specific netlist or class of netlists is specified by NetlislFile, and 
the class of target files is specified by TargetExtension. It expects 
an EXECUTABLE value. A value Ls required. 
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• Net 1 isterTopOpt ions—This key specifies options for the 
netlist reader when compiling the top level design. It expects an 
OPTIONS value or the keyword NONE. Included in this string 
should be the keywords SINFILE and JOUTFILE, in which the 
input and output files is substituted. In addition, the following 
keywords may appear. 

• SPART—The part passed to NGDBuild by the -p switch Ls 
substituted. It may include architecture, device, package and 
speed information. The syntax for a SPART specification is 
the same as described in the "Part Numbers in Commands” 
section of the "Introduction" chapter. 

• $ FA.WILY—The family passed to NGDBuild by the -p switch 
is substituted. A value is optional. 

• SDEVICE—The device passed to NGDBuild by the -p switch 
is substituted. A value is optional. 

• $PKG—The package passed to NGDBuild by the -p switch is 
substituted. A value is optional. 

• SSPEED—The speed passed to NGDBuild by the -p switch is 
substituted. A value is optional. 

• SLIBRARIES—The libraries passed to NGDBUILD. A value 
is optional. 

• SIGNORE LOCS—Substitute the -r option to ED1F2NGD or 
XNF2NGD if the NGDBUILD command line contained a -r 
option. 

• SADD PADS—Substitute the -a option to EDIF2NGD if the 
NGDBUILD command line contained a -a option. 

Tire options in the Net 1iatecTopOptlons line must be 
enclosed in quotation marks. 
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• NetlisterOptions—This key specifies options lor the netlist 
leader when compiling sub-designs. It expects an OPTIONS 
value or the keyword NONE. Included in this string should be 
the keywords SINFILE and SOUTF1LE. in which the input and 
output files is substituted. In addition, any of the keywords that 
may be entered for the NetlisterTopOptions key may also be 
used for the NetlisterOptions key. 

The options in the Met listerOpt ions line must be enclosed in 
quotation marks. 

• MetlisterDirectory—This key specifies the directory in 
which to run the netlist reader. The launcher changes to this 
directory before running the netlist reader. It expects a DIR value 
or the keywords SSOURCE, SOUIPUT, or NONE, where the 
path to the source netlist is substituted for SSOURCE, the direc¬ 
tory specified with the -dd option is substituted for SOUTPUT. 
and the current working directoiy is substituted for NONE. A 
value is optional. 

• NetlisterSuccessStatus—This key specifies the return 
code that the netlist reader returns if it ran successfully. It expects 
a NUMBER value or the keyword NONE. The number may be 
preceded with one of the following: =, <, >, or !. A value is 
optional. 

Value Types in Key Statements 

Tine value types used in the preceding key statements are the 

following. 

• RULENAME—Any series of characters except for a semicolon (;) 
and white space (for example, space, tab. newline). 

• EXTENSION—A followed by an extension Hut conforms to 
the requirements of the platform. 

• FILENAME—A file name that conforms to the requirements of 
the platform. 

• EXECUTABLE—An executable name that conforms to the 
requirements of the platform. It may be a full path to an execut¬ 
able or just an executable name. If it is just a name, then the 
SPATH environment variable is used to locate the executable. 
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• DIR—A directory name that conforms to the requirements of the 
platform. 

• OPTIONS—Any valid string of options for the executable. 

• NUMBER—Any series of digits. 

• STRING—Any series of characters in double quotes. 

System Rules File 

The system rules are shown following. Tine system rules file Ls not an 
ASCII file, but for the purpose of describing the rules, the rules are 
described using the same syntax as in the user rules file. This syntax 
is described in the "User Rules File” section. 

Note: If a rule attribute is not specified, it is assumed to have the 
value NONE. 

4 xnt2ngd rules 

RuleHanc = XNF_RULE; 

NctlistFilc * .xnf; 

TargetExtension = ,ngo; 

Netlister = xn£2ngd; 

NetlistcrTopOptions = "l-p $PAR7] -u l$X GNORE_LCCS] t-1 $LIBRARIE3} 
$INFILE $COTFILE*; 

NetlistcrCptions = "l-p SPARTl £$IGNORE_LOCS) (-1 $LIBRARIESJ $INFILE 
$GUTFILE"; 

NetlistcrDirectory = NONE; 

NetlistcrSuccessStatus = 0; 

RuleNanc = XTF_RULE; 

NetlistFilc = .xtf; 

TargetExtension = .ngo; 

Netlister = xnf2ngd; 

Net list erTopOpt ions = "l-p $PAR7) -u I $ XGNORE_LCCS) \-l ^LIBRARIES l 
$ INFILE $CUTFILE*; 

NetlisterCptions » *(-p SPARTl [$IGNORE_LOCS| l-l $LIBRARIES) $INFILE 
$CU7FILE H ; 

NetlistcrDirectory = NONE; 

Net 11sterSuccessStatus = 0; 

RuleNanc = XFF_RULE; 
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WotlistFile = .xff; 

TargetExtension = .ngo; 

Wot lister - xnf2ngd; 

Wet lastcrTopCptions - "(-p SPART] -u |$IGNORE_LCCS) \-l ^LIBRARIES l 
SlNFILE SCOTFILE*; 

WetlastcrCptions - •l-p SPARTl £$IGWORZ_LOCSl (-1 SLIBRARIESJ SlNFILE 
SOUIFILE"; 

WetiastcrDirectory = NOWE; 

NetlastcrSucccssStatus - 0; 

RuleNano = XG_RULE; 

WetlistFile = .xg; 

TargetExtension = .ngo; 

Wctlaster - xnt2ngd; 

WetlistcrTopOptions - m [-p SPART] -u |$IGNORE_LCCS) \-i ^LIBRARIESl 
SlNFILE SCOTFILE*; 

WetlastcrCptions = *[-p SPARTl (SlGWORE_LOCS) l-l SL1BRAR1ES) $IWFILE 
SCUTFILE H ; 

WetIastcrDirectory = NONE; 

WetlastcrSucccssStatus = 0; 

RulcHanc = SYN_XNF_RULE; 

WetlistFile = .sxnf; 

TargetExtension = .ngo; 

Wctlaster = xnt'2ngd; 

Wet listcrTopOpt ions - ■ (-p SPART) -u I $IGNORE_LCCS] -1 synopsys (-1 
^LIBRARIES| $INFILE SDUTFILE"; 

WetlastcrCptions = "(-p $PARTI ($IGNORE_LCXTS1 -1 synopsys 1-1 SLIBRARIESJ 
SlNFILE SCOTFILE*; 

Wet 1istcrDirectory = NOWE; 

WetlastcrSucccssStatus - 0; 

4 cdif 2 ngd rules 

RuleWane = EDN_RULE; 

WotlistFilo = .edn; 

TargctExtcnsion = .ngo; 

Wctlaster = cda£2ngd; 

WetlistcrTopOptions = " (SlGTORE^LDCSj |SADD_PADS] I-1 ^LIBRARIESl SIWFILE 
SOUTFILE H ; 

WetlastcrCptions = "-noa I $ IGNORE_LCCS] (-1 SLIBRARIESJ SIWFILE SCOTFILE*; 
Wet 1istcrDirectory = NOWE; 

WetlastcrSucccssStatus - 0; 
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RuleNanc = EDF_RULE; 

NctiistFilc = .cdf; 

TargetExtension = .ngo; 

Net lister = cdi£ 2 ngd; 

Net 1isterTopOptions = "($IGWDRE_LOCSJ I$ADD_PADS) I-1 $LIBRARIES} $INFILE 
$£UTFILE"; 

NetiistcrCptions = "-noa |$IGNORE_LCCS] (-1 $LIBRARIE3} $INFILE $CU7FILE*; 
NetlistcrDirectory = NONE; 

Net 1isterSuccessStatus - 0; 

RuleNanc = EDIF — RULE; 

NetlistFilc = .ediff 
TargetExtension = .ngo; 

Net lister - cdi£2ngd; 

NetlistcrTopOptions = "[$ IGttf)RE_I/)CS1 |$ADD_PADS) 1-1 $LIBRARIE31 $INFILE 
$OU7FILE"; 

NetlistcrCptions = *-noa I $IGNORE_LCCS] 1-1 $LI BRARIEG1 $INFILE $CU7FILE*; 
NetlistcrDirectory = NONE; 

NetlistcrSucccssStatus - 0; 

RuleNanc = SYN_EDIF_RULE; 

NetlistFilc = .sedit; 

TargetExtension = .ngo; 

Net lister - cdi£2ngd; 

NetlistcrTopOptions - NONE; 

Net listcrCptions - *-l synopsys | $XGNORE_LCCS] 1-1 $LIBRARIES \ $INFX LE 
$OU7FILE"; 

NetlistcrDirectory = NONE; 

NetlistcrSucccssStatus = 0; 

4 other rules 

********4 *********4**t*4t*t*4t*t*4t*t**t*4**t*4****4* 

RuleNanc = PLD_RULE; 

NetlistFilc = -pld; 

TargetExtension = .xnf; 

Netlistcr - rcadpld; 

NetlistcrTopOptions - "-£ $INFILE -t -ox $CXJTFILE*; 

NetlistcrCptions = *-f $INFILE -ox $OUTFILE"; 

NetlistcrDirectory = NONE; 

NetlistcrSucccssStatus = 0; 
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Rules File Examples 

Tile following sections provide examples of system and user rules. 
The first example explains one of the system rules presented in the 
preceding "System Rules File" section. This example is the basis for 
understanding the ensuing user rules examples. 

Example 1: XNF_RULE System Rule 

As shown in the "System Rules File" section, the XNF RULE system 
rule is defined as follows. 

RulcNanc = XNF_RULE; 

NetlisCFilc = .mi; 

Target Ext on:. Ion = .ngo; 

Netlister = xn£2ngd; 

NetlistcrTcpOptions = *(-p $PART) -U |5IGNORE_LCCS) (-1 $LIBPARIE3| 
SlNFILE SCOTFILE’; 

NetlisterOptions = ‘ I-p SPARr! (SIGNOPE_LOCS) ( -1 S LIBRARIES I SlNFILE 
SOUTFILE"; 

NetlisterDirectory = HONE; 

Netils terSuccess Status = 0; 

Tine XNF RULE instructs the Netlister Launcher to use XNF2NGD to 
translate an XNF file to an NGO file. If the top-level netlLsl is being 
translated, the options defined in NetlisterTopOptions are used; if a 
lower-level netlist is being processed, the options defined by Nellis- 
teiOptions are used. Tine -u option is used on the top-level netlist. but 
not on lower-level netlists. Because NetlisterDirectory is NONE, the 
Netlister Launcher runs XNF2NGD in the current working directory 
(the one from which NGDBuild was launched). The launcher expects 
XNF2NGD to issue a return code of 0 if it was successful; any other 
value is interpreted as failure. 
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Example 2: User Rule 

// UPF Example 2 

RulcNanc = OTHER_KULE; // end-of-linc eonments ace also allowed 
NetlistFil® = .oth; 

Target. Ext ension - .xn i; 

Nctlistcr = other2xn£; 

Net lister CpCions = "SINFILE SOUTFILE*; 

NetlistcrSucccssStatus = 1; 

Tine user rule OTHER RULE defines a completely new translation, 
from a hypothetical OTH file to an XNF file. To do this translation, 
the other2xnf program is used. The options defined by 
NetlisterOptions are used for translating all OTH files, regardless of 
whether they are top-level or lower-level netlists (because no explicit 
NetlislerTopOptions is given). The launcher expects other2xnf to 
issue a return code of 1 if it was successful, any other value be 
interpreted as failure. 

After the Netlisler Launcher lias used OTHER RULE to run 
other2xnf and create an XNF file, it uses the XNF RULE system rule 
(shown in the preceding section) to translate the XNF file to an NCO 
file. 

Example 3: User Rule 

// URF Example 3 
RulcHanc = XNF_LIB_RU1.E; 

HetlistFilc = .xnf; 

TacgctExCcnaion “ .ngo; 

Netlistcrept ions = ‘-l xlltnxun SINFILE SOUIFILE"; 

Because both the NetlistFile and TargetExtension of this user rule 
match those of the system rule XNF RULE (shown in the "Example 1: 
XNF RULE System Rule" section), the XNF LIB RULE overrides the 
XNF RULE system rule. Any settings that are not defined by the 
XNF LIB RULE are inherited from XNF RULE. So XNF LIB RULE 
uses the same netlister (XNF2NGD), the same top-level options, the 
same directory, and expects the same success status as XNF RULE. 
However, when translating lower-level netlists, the options used are 
only "~\ xilinxun SINFILE SOUTF1LE." (There is no reason to use "-1 
xilinxun" on XNF2NGD; this is for illustrative purposes only.) 
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Example 4: User Rule 

// URF Example 4 
RulcNanc = STAT£_XNF_RULE; 

HctlistFilc = state.xnt; 

TargetExtenslon - .ngo; 

Netlister = stato2rgd; 

Although the NetlistFile is a complete tile name, this user rule also 
matches the system rule XNF RULE (shown in the "Example 1: 

XNF RULE System Rule" section), because the extensions of Netlist¬ 
File and TargetExtension match. When the Netlister Launcher tries to 
make a tile called state.ngo. it uses this rule instead of the system rule 
XNF RULE (assuming that state.xnf exists). As with the previous 
example, the unspecified settings are inherited from the matching 
system rule. The only change Ls that the fictitious program state2ngd 
is used in place of XNF2NGD. 

Note that if XNF LIB. RULE (from the example in the "Example 3: 
User Rule" section) and this rule were both in the user rules file, 
STATE XNF RULE includes the modifications made by 
XNF LIB RULE. So a lower-level state.xnf is translated by running 
state 2 ngd with the "-1 xiiinxun" option. 

File Names and Locations 

Following are some notes about file names and notations in 
NGDBuild. 

• An intermediate file has the same root name as the design that 
produced it. An intermediate file is generated when more than 
one netlist reader is needed to translate a netlist to a NGO file. 

• Netlist root file names in the seaich path must be unique. For 
example, if you have the design state.edn, you cannot have 
another design named state.xnf in any of the directories specified 
in the search path. 

• NGDBuild and the Netlister Launcher support quoted file 
names. Quoted file names may have special characters (for 
example, a space) that am not normally allowed. 

• If the output directory specified in the call to NGDBuild is not 
writable, an enor is displayed and NGDBuild fails. 
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Numerics 

-10ps option, NGD2VER. 20-5 


-a option 

BitGen. 16-5 
ED1F2NGD, B-3 
NGD2ED1F. 19-1 
NGD2VHDL. 21-5 
NGDBuild. 4-7 
TRCE. 14-4 

AddressLines option, 16-12 
advanced analysis, 14-4 
-aka option 

NGD2VER. 20-5 
NGD2VHDL, 21-5 
ALF files, 18-5. A-l 
ALLCLOCKNETS keyword 
with MAXDELAY. 6-63 
with MAXSKEW. 6-61 
with PERIOD. 6-31. 6-32 
ALLPATHS keyword. 6-62 
annotated netlist data (XFLOVV). 22-28 
application data files (XFLOW). 22-30 
architectures supported 
for BitGen. 16-1 
for EDIF2NGD, B-l 
for LCA2NCD. 9-1 
for MAP. 8-1 
for MAP options. 8-6 
for NGD2ED1F, 19-1 


for NGD2VER. 20-1 
for NGD2VHDL. 21-1 
for NGDAnno. 18-1 
for NGDBuild. 4-1 
for PAR. 12-1 
for PARTGEN. 3-1 
for physical DRC. 11-1 
for PIN2UCF. 13-1 
for PROMGen. 17-1 
for SPEEDPR1.NT. 15-1 
for TRACE. 14-1 
for XFLOW. 22-1 
for XNF2NGD, B-7 
area setting. 8-9. 8-14 
asterisk. 6-27 

AT&T Verilog simulator. 20-9 
attributes, definition. 6-4 
automount points. 12-47 

B 

-b option 

BitGen. 16-5 
MAP. architectures. 8-6 
MAP. description. 8-7 
NGD2ED1F. 19-5 
PROMGen. 17-5 
back-annotation 

CPLD command. 2-24 
description. 2-3. 18-2 
errors. 8-23 

flow diagram. 2-22. 2-23. 18-3 
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global signals 
Virtex. 18-9 
XC3X00, 18-9 
XC4000and Spartan. 18-9 
XC5200. 18-9 
netllst writers. 2-24 
NGD2ED1F. 2-24 
NGD2VER. 2-24 
NGD2VHDL. 2-25 
NGDAnno, 2-23 
translation options. 2-26 
balanced setting. 8-9. 8-14 
balanced.opt. 22-9 
BEL. definition, 1-12 
BGN files. 16-3. A-l 
bidirectional pads. 7-4 
BIT files 

creating with XFLOW. 22-6 
description. 16-4. A-l 
disabling. 16-38 
loading downward. 17-5 
loading up or down. 17-6 
loading upward. 17-7 
bit swapping 

description. 17-3. 17-4 
disabling. 17-5 
BitGen 

-a option. 16-5 
-b option. 16-5 
BGN files. A-l 
BIT files. A-l 
-d option. 16-6 
description. 16 - 1 . 16-2 
disabling DRC. 16-6 
DRC files. A-l 
flow diagram. 16-2 
-g option. 16-6-16-38 
-h option. 16-38 
input files. 16-4 
-j option. 16-38 
-1 option. 16-38 


LL files. A-3 
-m option. 16-39 
MSK files. A-3 
-n option. 16-39 
options. 16-5 
output files. 16-4 
RBT files. A-5 
supported families. 16-1 
syntax. 16-3 
-t option. 16-39. 16-40 
-u option. 16-41 
-w option. 16-41 
XFLOW. 22-6 
bitstream generation. 2-3 
BLD files. 4-6. A-l 
block 

allowing unexpanded. 4-10 
check, logical DRC. 7-2 
check, physical DRC. 11-4 
delay symbols, for path tracing. 6-64 
delays, simulating with. 2-26 
placement. 2-9 
STARTUP, VHDL only. 21-9 
STARTUP VIRTEX, VHDL only, 21-11 
blocks 

optimized. 8-27 
removed. 8-27 
trimmed. 8-27 
bonded I/Os. 12-16 
BSCAN primitive. 7-3 
BSCAN Config option. 16-13 
BSCAN Status option. 16-13 
BSReadback option. 16-22 
BSReconfig option. 16-22 
BUF primitive. 7-3 
buffers, using to model delays, 19-5 
BUFGP primitives. 2-15. 8-7 
BUFGS primitives. 2-15 
bus 

definition. 1-12 
matching. B-16 
matching in Virtex. B-17 
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naming conventions, B-16 
order in Verilog files. 20-12 
order inVHDL files. 21-18 


< option 

MAP. architectures. 8-6 
MAP. description. 8-8 
NGD2ED1F, 19-5 
PAR. 12-7 

cables, download. 2-32 

Cadence Synergy synthesis tool. 20-5 

case-sensitivity 

command line options. 1-2 
keywords. 6-5. 6-26. 6-49 
CClk.Nosync. 16-11 
Cclk Sync. 16-11 
CclkPin option. 16-31 
-cd option. 20-5 
cell 

ROC. 21-11 
ROCBUF. 21-13 
STARTBUF. 21-10 
STARTBUF V1RTEX. 21-11 
TOC. 21-13 
TOCBUF. 21-14 
chip check, physical DRC. 11-4 
circuit cycles. 12-11, 14-6. 14-17 
CKBUF. 7-3. 8-7 
CLBMAP symbol. 2-9 
CLBs. 8-8 
cleanup 

passes, delay-based. 12-9 
passes, delay-based router, 12-8 
routers, strategies for using. 12-7 
routing. 12-19 
clock 

buffer check. 7-4 
buffers. 8-7 

distribution, global. 2-14 

enable. 2-15. 2-16 

period see PERIOD constraint 
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resource, global. 2-15 
sense, defining. 6-26 
skew. 14-13. 14-14 
clocks 

at different chip inputs. 14-15 
derived, specifying, 6-33 
in synchronous designs. 2-15 
periods, defining. 6-30. 6-31 
skew, for TRCE. 14-8 
stamp, for TRCE. 14-8 
through multiple buffers. 14-14 
clock-to-output propagation delays. 14-19 
-cm option 

architectures. 8-6 
description. 8-9 
CMOS. 16-8. 16-23 
colons, as separators. 6-6 
combinatorial loops, 6-48. 12-11. 14-6 
command files. 1-6 
command line see commands 
commands 

file, executing, 9-4. 12-9. 14-5. 17-5 
options, entering. 1-2 
part numbers in. 1-4 
COMP "iob name '. 6-39 
compile scripts, Verilog. 20-13 
component, definition. 1-10 
-config flow type, XFLOW. 22-6 
ConfigRate option 
Spartan2. 16-30 
Virtex. 16-30 

XC4000 and Spartan. 16-14 
XC5200. 16-23 
configuration 

clock rate. 16-14. 16-23. 16-30 
-g option. 16-6-16-38 
constraints 

controlling implementation. 2-8 
DROP.SPRC. 6-66 
files, timing specifications. 6-6 
in PCF files. 10-3 
in UCF files. 5-1 
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interaction between. 10-3 
location see location constraints 
location see location constraints 
logical, sources of. 10-1 
net delay. 14-12 
net skew. 14-12 
path delay. 14-12 
pin locking. 13-2 
priorities. 6-67 
prorating, 6-60 
temperature. 6-60 
timing see timing constraints 
VOLTAGE. 6-60 
Constraints Editor. 6-6 
constructive 

placement. 12-18 
routing. 12-18 
CONTROL-BREAK 
halting MAP. 8-32 
halting TRACE. 14-38 
CONTROL-C 

halting MAP. 8-32 
halting TRACE. 14-38 
halting turns engine. 12-50 
Converting. 4-3 
CORE Generator. 2-7 
cost tables, placer. 12-16 
cost-based 

PAR, description, 12-2 
router cleanup passes. 12-7 
counters. 2-17 
cover mode. 8-9 
CPLD 

command, 2-24 
fitter. GYD files. A-2 
fitter, JED files. A-2 
programming data (XFLOV), 22-27 
report files (XFLOW). 22-31 
cpld.flw. 22-20 
CRC option 

XC4000 and Spartan. 16-14 
XC520O. 16-23 


critical nets. 16-41 
cycles 

circuit. 12-11, 14-6 
detecting in TRACE. 14-17 

D 

-d option 

BitCen. 16-6 
MAP. architectures. 8-6 
MAP. description. 8-9 
PAR. 12-8 
PROMCen. 17-5 
data feedback. 2-16 
DATA files. A-l 
data sheet reports 

comparing with verbose report. 14-33 
description. 14-19 
obtaining a complete report. 14-21 
DC files. A-l 
-dd option. 4-7 

debug mode, turns engine. 12-48 
debugging, turns engine. 12-49 
default flow files, XFLOW, 22-3 
delay file 

description. 12-33. 12-34 
tilde. 12-33 
delay-based 

cleanup passes. 12-9 
router cleanup passes, 12-8 
delays 

modeling with buffers. 19-5 
nets. 6-62 

derived clocks, specifying. 6-33 
design entry 

controlling implementation with 
constraints. 2-8 
description. 2-1. 2-4 
flow diagram. 2-5 
library elements. 2-5 
schematic entry. 2-5 
text-based entry. 2-8 
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design flow 

description. 2-1 
now diagrams. 2-2. 2-4 
design implementation 
description. 2 - 1 . 2-10 
flow diagrams. 2-11. 2-12 
mapping. 2-9 
design performance. 2-14 
design size. 2-14 

design techniques, for FPGAs. 2-14 
design verification 

description. 2-2. 2-18 
now diagrams. 2-19. 2-20 
functional simulation. 2-27 
schematic-based simulation. 2-26 
timing simulation. 2-27 
tools. 2-21 

designs, scoring routed ones. 12-41 
-detail option 

MAP. architectures. 8-6 
MAP. description. 8-9 
device 

attributes. 3-7 
definition. 1-10 

speed, annotating to NGA file. 18-8 
devices, listing with PARTGEN. 3-4 
DFS method 

description. 12-11. 14-5 
differences with kpaths. 12-11. 14-6 
-dfs option 
PAR. 12-9 
TRCE. 14-4 
Direct Input Pin. 8-9 
DISABLE keyword. 6-63 
division, for time delays. 6-56 
DLY files. A-l 

DONE/PROGRAM pin. 16-7 
Done cycle option. 16-36 
DoneActive option 

XC4000 and Spartan. 16-14. 16-15 
XC5200. 16-23. 16-24 


Done Pin option 
Sparlan2. 16-31 
Virtex. 16-31 
XC3X000. 16-6 
XC4000 and Spartan. 16-15 
XC5200. 16-24 
DonePipe option. 16-37 
DoneTime option, XC3XOOO. 16-7 
double quotes. 6-6 
download cables, description. 2-32 
DRC 

see also logical DRC 
description. 2-32 
disabling for BitGen. 16-6 
file, BitGen. 16-5 
files. A-l 
TDR files. A-5 
DRC command, physical 
compatible families. 11-1 
description. 11-2 
-e option. 11-3 
errors. 11-5 

incomplete programming. 11-4 
input files. 11-3 
-o option. 11-3 
output files. 11-3 
report files. 11-3 
-s option. 11-3 
syntax. 11-2 
-v option. 11-3 
warnings. 11-5 
-z option. 11-1 
DRC. logical 

block check. 7-2 
clock buffer check. 7-4 
description. 7-1 
name check. 7-4 
net check. 7-3 
netlist writers. 7-2 
pad check. 7-3 
primitive pin check. 7-5 
running automatically, 7-2 
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types of tests. 7-2 
DriveDone option. 16-37 
DrivePDStatusPin option. 16-32 
DROP SPEC constraint. 6-66 

E 

-e option 

DRC command. 11-3 
PAR. 12-9 
TRCE. 14-5 
-ed option 

with -wd option. 22-14 
XFLOW, description. 22-14 
XFLOVV, example. 22-14 
ED1F files 

description. B-4 
writing all properties to. 19-4 
EDIF2NCD 

-a option. B-5 
description. B -2 
-f option. B-5 
flow diagram. B-2 
input files. B-4 
-1 option. B-5 
options. B-5 
output files. B-4 
-p option. B-6 
-r option. B-6 
supported families. B-1 
syntax. B-3 
EDN files. 19-4. A-2 
effort level 

-1 PAR option. 12-12 
-ol PAR option. 12-13 
placer,-pi PAR option. 12-14 
router, -rl PAR option. 12-15 
ENABLE keyword. 6-63 
End Program construct. 22-22 
entity 

naming top-level. 21-7 
suppressing. 21-5 


environment 

problems, turns engine. 12-49 
variables, for turns engines. 12-47 
ENWRITE. 6-4. 6-5. 6-2.3 
EPL files. A-2 
error reports 

-dfs vs-kpaths. 14-18 
generating with TRCE. 14-5 
TRACE. 14-28. 14-29 
errors 

DRC command. 11-5 
MRP files. 8-26 
net delay. 14-11 
net skew. 14-11 
offset. 14-11 
path delays. 14-11 
EXACT mode. 8-11.8-22 
exact option for PAR. 12-21 
EXCEPT keyword. 6-25. 6-69 
exclusion, creating groups. 6-25 
Executable construct. 22-21. 22-22 
existing groups, new groups. 6-22 
EXO files. A-2 
Export Directory. 22-14 
ExportDir. 22-20 
Exports construct. 22-22 
ExpressMode option. 16-16 
external setup/hold requirements. 14-19 


-f option 

architectures supported for MAP. 8-6 

description. 1-6 

EDIF2NGD. B-3 

NGD2ED1F. 19-5 

NGD2VER. 20-6 

NGD2VHDL. 21-5 

NGDAnno, 18-7 

NGDBuild. 4-8 

PAR. 12-9 

TRACE. 14-5 

XNF2NGD. B-10 
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FALLING keyword, 6-26. 6-69 
false paths, 12-11. 14-6 
families supporled 
for BilGen. 16-1 
for ED1F2NGD. B-l 
for LCA2NCD. 9-1 
for MAP. 8-1 
for NGD2EDIF. 19-1 
for NGD2VF.R. 20-1 
for NGD2VHDL. 21-1 
for NGDAnno. 18-1 
for NC.DBuild. 4-1 
for PAR. 12-1 
for PARTGEN. 3-1 
for physical DRC. 11-1 
for PIN2UCF. 13-1 
for PROMGen. 17-1 
for SPEEDPR1NT. 15-1 
for liming constraints, 6-1 
for TRACE. 14-1 
for XFLOW. 22-1 
for XNF2NGD. B-7 
fast, mntime.opt. 22-9 
files 

see also input or output files 
in commands. 1-2 
netlist, naming. 4-11 

overwriting, 12-16 

package, creating. 3-5.3-6 
partlist.xct. 3-5. 3-6 
redirecting messages. 1-3 
simulation files, XFLOW. 22-8 
Filis category, XFLOW option files. 22-11 
-fit flow type 

option files. 22-7 
XFLOW, description. 22-7 
fitting, description, 2-3 
five-input functions. 8-12 
five-V .Tolerant JO. 16-13 
Rag construct. 22-21 
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flip-flops 

defining subgroups. 6-26 
grouping with TNM. 6-19 
grouping with TNMs, 6-18. 6-20 
tegisler ordering. 8-19 
Fkiorplanner 

-fp option. 8-10 
MFP files. 8-4. A-3 
flow files 

defaults. 22-3 
example. 22-24 
ExportDir. 22-20 
program blocks. 22-21 
Repo it Dir. 22-20 
user command blocks. 22-22 
XFLOW, description. 22-19 
flow types 

description. 22-6 
examples. 22-5. 22-6 
option simulation files. 22-8 
relationship with option files. 22-4 
search hierarchy. 22-6 
FLW files. A-2 
FMAP symbol. 2-9 
forward tracing. 6-12. 6-14. 6-20. 6-31 
-fp option. 8-4. 8-6. 8-10 
FPGA Editor 

block checks, 11-4 
command log files, A-2 
description. 2-13 
net checks. 11-4 
NGDAnno. 2-23 
NMC files. A-4 
PCF files. A-4 
RCV files. A-5 
SCR script files. A-5 

FPGA programming data (XFLOW). 22-27 

FPGA report files (XFLOW). 22-30 

fpga.flw, 22-20. 22-24 

fpga editor.ini script. A-2 

fpga editor user.ini files. A-2 

fpga editor user.ini script. A-2 
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FROM-THRU 
examples. 6-71 
with TPSYNC, 6-54 
FROM-THRU-TO examples. 6-71 
FROM-TO 

examples. 6-8. 8-49. 6-71 
rules for using. 6-49 
syntax. 6-48. 6-72 
with TPSYNC. 6-54 
with TPTHRU. 6-54 
-fsim flow type 

option simulation files. 22-8 
XFLOVV, description. 22-8 

fsim.flw. 22-20 

FSMAP symbol. 2-9 
functional simulation 
data (XFLOW), 22-28 
description. 2-9. 2-27 


G 

-g BitGen option 
description. 16-6 
SpartanZ 

CclkPin. 16-31 
ConfigRate. 16-30 
Done .cycle. 16-36 
DonePin. 16-31 
Done Pipe. 16-37 
DriveDone. 16-37 
DrivePDStatusPin. 16-32 
Gdkdel, 16-30 
GSR cycle. 16-35 
GTS_cyde. 16-36 
GWE_cycle. 16-35 
LCK .cycle. 16-36 
MOPin. 16-32 
Ml Pin. 16-32 
M2Pin. 16-33 
PDStatusPin. 16-33 


Persist. 16-36. 16-37 
PowerdownPin. 16-33 
PowerupClk. 16-31 
ProgPin. 16-33 
ReadBack. 16-29 
Security. 16-38 
StartupClk. 16-30 
TckPin. 16-34 
TdiPin. 16-34 
TdoPin. 16-34 
TmsPin. 16-35 
UserlD. 16-38 
Virtex 

CclkPin. 16-31 
ConfigRate. 16-30 
Done, cycle. 16-36 
DonePin. 16-31 
DonePipe. 16-37 
DriveDone. 16-37 
Gdkdel. 16-30 
GSR.cycle. 16-35 
GTS_cycle. 16-36 
GIVE. cycle. 16-35 
LCK.cycIe. 16-36 
MOPin. 16-32 
Ml Pin. 16-32 
M2Pin, 16-33 
Persist. 16-36. 16-37 
ProgPin, 16-33 
ReadBack. 16-29 
Security. 16-38 
StartupClk. 16-30 
TckPin. 16-34 
TdiPin. 16-34 
TdoPin. 16-34 
TmsPin. 16-35 
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UserlD. 16-38 
XC3XOO 

Done Pin, 16-6 
DoneTime. 16-7 
Input. 16-8 
LC Alignment. 16-8 
Oscillator. 16-8 
Readback. 16-9 
ResetTime. 16-9 
XC4000 and Spartan 
AddressLines. 16-12 
BSCAN_Config, 16-13 
BSCAN.Status, 16-13 
Cclk. Nosync, 16-11 
CcIk_S)nc, 16-11 
ConfigRate. 16-14 
CRC. 16-14 
description. 16-10 
DoneActive, 16-14. 16-15 
Done Pin. 16-15 
ExpressMode. 16-16 
f5V Tolerant lO. 16-13 
GSRInactive. 16-16. 16-17 
Input. 16-17 
LC Alignment. 16-17 
MOPin, 16-18 
Ml Pin. 16-18 
M2Pin. 16-18 
Output. 16-18 
OutpulsActive. 16-19 
Power Down. 16-20 
Read Abort. 16-20 
ReadCapture. 16-20 
ReadClk. 16-21 
startup sequences. 16-10 
StartupClk. 16-21 


SyncToDone, 16-21 
TdoPin. 16-22 
Uclk Nosync. 16-12 
Udk.Sync, 16-12 
XC5200 

BS Readback. 16-22 
BSReconfig, 16-22 
ConfigRate. 16-23 
CRC. 16-23 

DoneActive. 16-23. 16-24 
Done Pin. 16-24 
GSRInactive, 16-25 
Input. 16-23. 16-26 
LC_Alignment. 16-26 
OscClk. 16-26 

OutputsAdive. 16-26. 16-27. 16-29 
ProgPin. 16-28 
ReadAbort, 16-28 
ReadCapture. 16-28 
ReadClk. 16-28 
StartupClk. 16-29 

gate sense, defining latch subgroups. 6-27 
gated clocks. 2-15. 2-16. 2-17 
Gclkdel option. 16-30 
-gf option 

MAP. architectures, 8-6 
MAP. description. 8-10 
PAR. 12-9 
global 

clock distribution. 2-14 
clock resources. 2-15 
OFFSET constraint. 6-37 
reset, as port. 20-6. 21-5 
reset, back-annotation 
XC3X00. 18-9 
XC5200, 18-9 

set/reset, back-annotation 
Virtex. 18-9 
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XC4000 and Spartan. 18-9 
tristate signal, as port. 20-9. 21-8 
Global Set/Reset, simulation. 2-30 
-gm option 

MAP, architectures. 8-6 
MAP. description. 8-11 
PAR. 12-10. 12-22 
-gp option 

NGD2VER. 20-6 
NGD2VHDL. 21-5 
groups 

by clock sense, with T1MEGRP. 6-26 
by exclusion, with T1MEGRP. 6-25 
by pattern matching. 6-27 
specifying. 6-7 
TIMEGRP. 6-22 
GSR cycle option. 16-35 
GSRInactive option 

XC4000 and Spartan. 16-16. 16-17 
XC5200. 16-25 
GTS..cycle option. 16-36 
guaranteed setup and hold. 14-21. 14-22. 
18-10 
guide 

data (XFLOW). 22-29 
designs, using, 12-20 
files. NCD files. 8-1 

mode. 12 - 10 . 12-22 

mode option. 8-11 
NCD file. 12-9 
NCD file, for MAP. 8-10 
reporting. 12-39 
guided 

mapping, description. 8-21 
mapping, -gm option. 8-11 
mapping, HDL designs. 8-23 
mapping, illustration. 8-22 
mapping. MDF files. 8-5 
mapping. MFP file. 8-10 
mapping. MFP files. 8-4 
PAR. description. 12-20 
PAR. incremental designs. 12-20 


PAR. PCI cores. 12-22 
PAR. with HDL designs. 12-22 
CAVE cycle option. 16-35 
GYD files. 13-4. A-2 


-h option 

BitCen. 16-38 
XFLOW, description. 22-14 
HDL 

advantages. 2-8 
description. 2-8 
HDL designs 

guided mapping. 8-23 
guided PAR. 12-22 
TNM NET. 6-21 
HDL-based simulation 
description. 2-28 
flow diagram. 2-28 

post-synthesis functional simulation. 
2-29 

RTL simulation. 2-28 
simulation points. 2-29 
-help option. 1-3. 17-5 
HEX files. A-2 
hierarchical 
design. 2-6 
names. 2-7 

hierarchy, retaining in design 
NCD2VER, 20-7 
NGD2VHDL. 21-6 
high effort.opt. 22-9 
HMAP symbol. 2-9 
hold times. 14-22 


-i option 

NGD2ED1F. 19-5 
PAR. 12-10 
PARTCEN, 3-4 
I/O startup sequence. 16-21 
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I/Os 

bonded. 12-16 
packing registers. 8-16 
releasing from 3-state condition. 16-19. 
16-26 
identifiers 

in Verilog. 20-12 
in VHDL. 21-19 

user-defined names as comments in 
Verilog netlist. 20-5 
user-defined names as comments in 
VHDL netlist. 21-5 
-implement flow type 
balanced.opt. 22-9 
example. 22-5 
examples. 22-9 
fast runtime.opt. 22-9 
high effort.opt. 22-9 
option files. 22-9 
XFLOVV, description. 22-9 
implementation 

tools, invoking. 1-1 
XFLOW -implement. 22-9 
in-circuit verification 
description. 2-32 
Design Rule Checker. 2-32 
incremental designs, PAR. 12-20 
Input construct. 22-21 
input files 

BitGen, 16-4 
DRC command. 11-3 
ED1F2NGD. B-4 
LCA2NCD, 9-3 
MAP. 8-4 
NGD2ED1F. 19-4 
NGD2VER. 20-4 
NGD2VHDL. 21-4 
NGDAnno. 18-5 
NGDBuild. 4-4 
PAR. 12-6 
PARTCEN. 3-2 
PIN2UCF. 13-4 


PROMGen. 17-3 
TRCE. 14-3. 14-10 
turns engine. 12-43 
XFLOW. 22-18 
XNF2NGD. B-10 
input functions, mapping to. 8-11 
Input option 

XC3X000. 16-8 
XC4000 and Rattan. 16-17 
XC5200. 16-23. 16-26 
input pads 

connecting to primitives. 7-3 
TNMs, 6-12 

input-to-output propagation delays. 14-20 
INST name. 6-6 
instance name 

specifying in SDF and TVHD file. 21-7 
specifying in TV file. 20-9 
interconnects, unused. 16-39. 16-40 
Intermediate Failing Timespec Summary. 
12-26 

intermediate files see NGO files 
invalid characters, replacing in Verilog file. 
20-6 

inverted signal names. 6-6 
io I pad. 6-65 
lOB configurations 
Spartan2. 6-64. 6-65 
Virtex. 6-64. 6-65 
lOB registers 

reporting timing constraints. 6-3 
specifying timing constraints. 6-3 
lOBs 

input threshold levels. 16-26 
properties. 8-28 
setting output levels. 16-18 
-ir option 

architectures. 8-6 
description. 8-11 
iterations 

multiple, for PAR. 12-23 
-n PAR option. 12-13 
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router. 12-10 

ITR 

files. A-2 
report. 12-27 

J 

-j option. 16-38 
JED files. A-2 


-k option 

description. 8-11 
MAP. architectures. 8-6 
MAP. description. 8-12 
PAR. 12-10 
keywords 

ALLCLOCKNETS. 6-31 
as identifiers, 6-11 
case-sensitivity. 6-5. 6-26. 6-49 
DISABLE. 6-63 
ENABLE. 6-63 
EXCEPT. 6-25. 6-69 
FALLING. 6-26. 6-69 
in quotation marks, 6-11 
PRIORITY. 6-58 
RISING. 6-26. 6-69 
TRANSHI. 6-27. 6-69 
TRANSLO. 6-27. 6-69 
-kpaths 

analysis, differences with DFS. 12-11, 
12-12 

differences from -dfs. 14-6. 14-7 
PAR option. 12-10 
TRCE option. 14-5 


-1 option 

BitGen. 16-38 
ED1F2NGD. B-5 
MAP. architectures. 8-6 
MAP. description. 8-12 


NGD2ED1F. 19-6 
NGDBuild. 4-8 
PAR. 12-12 
XNF2NGD. B-ll 
L2N files. 9-3. A-2 
latches 

grouping with TNMs, 6-18 
subgroups, defining with T1.Y1EGRP. 
6-27 

LC Alignment option 
XC3X000. 16-8 
XC4000 and Spartan. 16-17 
XC5200. 16-26 
LCA files 

description. 9-1. A-2 
translating unnamed components. 9-4 
unnamed components. 9-4 
LCA2NCD 

compatible families. 9-1 
description. 9-1 
-f option. 9-4 
flow diagram. 9-2 
input files. 9-3 
L2N files. A-2 
MDF files. A-3 
N'CD file output name. 9-2 
options. 9-3 
output files. 9-3 
-p option. 9-3 
placement. 9-3 
syntax. 9-2 
-w option. 9-4 
LCK cycle option. 16-36 
length count. 16-8. 16-17. 16-26 
LEVERAGE mode. 8-11. 8-22. 8-13 
leverage option for PAR. 12-21 
libraries,searching. 4-8. B-5. B-ll 
library elements 
description. 2-5 
macros. 2-6 

LL files. 16-4. 16-38. A-3 
LOC see location constraints 


Index -12 


Xilinx Development System 




Index 


local scope, for dedicated signals. 19-6 
location 

constraints, eliminating. 4-9 
properties, filtering. B-6. B-12 
LOG files. 20-4. 20-6. 21-4. 21-6. A-2 
-log option 

NGD2VER. 20-6 
NGD2VHDL. 21-6 
LogiBLOX 

description. 2-7 
MEM files. A-3 
NGC files. A-4 
logic 

added by MAP. 8-28 
allocation file. 16-38 
expanded by MAP. 8-28 
optimization, disadvantages. 8-14 
optimization, effort. 8-13 
optimization, style. 8-14 
removed from NGD files. 8-27 
replication. 8-12 
unused. 8-16 

logical constraints, in UCF files. 5-1 
logical DRC 

see also DRC, logical 
block check. 7-2 
clock buffer check. 7-4 
description. 7-1 
name check. 7-4 
net checks. 7-3 
netlist writers. 7-2 
pad check. 7-3 
primitive pin check. 7-5 
running automatically, 7-2 
types of tests. 7-2 
logicdelay. 14-13 
longlines. pullups. 12-19 
LUTs. reducing. 8-9 


M 

-m option 

BitCen. 16-39 
PAR. 12-12 
MOPin option 

Spartan2. 16-32 
Virtex. 16-32 

XC4000 and Spartan, 16-18 
Ml Pin option 

Spartan2. 16-32 
Virtex. 16-32 

XC4000 and Spartan, 16-18 
M2Pin option 

Spartan2. 16-33 
Virtex. 16-33 

XC40G0 and Spartan, 16-18 
macros 

pins, attaching TPSYNC. 6-52 
Relational!)' Placed. 2-6 
soft. 2-6 
synthesis, 2-6 
TMNs. 6-14 
MAP 

added logic. 8-28 

-b option. 8-7 

-c option. 8-8 

-cm option. 8-9 

compatible families. 8-1 

-d option. 8-9 

description. 8-2 

-detail option. 8-9 

Directive Files see MDF files 

EXACT mode. 8-22 

expanded logic. 8-28 

Floorplanner File see M FP files 

flow diagram. 8-2 

-fp option. 8-10 

-gf option. 8-10 

-gm option. 8-11 

halting. 8-32 

input files. 8-4 

invoking. 8-2 


Development System Reference Guide 


Index-13 




Development Sj/itCm Rt’feh’/tci Guide 

-ir option, 8-11 
-k option. 8 - 11 . 8-12 
-1 option. 8-12 

LEVERAGE mode. 8-22. 8-23 

MDF files. A-3 

MRP files. 8-25 

MRP files, description. A-3 

NGM files. A-4 

-o option. 8-13 

-oe option. 8-13 

options and architectures, 8-6 

-os option. 8-14 

output files. 8-5 

-p option. 8-15 

PCF files. 8-3. A-4 

-pr option. 8-16 

process. 8-17. 8-18 

-r option. 8-16 

register ordering. 8-19 

Report Files see MRP files 

simulating results. 8-23 

Spartan2. guide files. 8-3 

syntax. 8-3 

to 5-input functions. 8-12 
-u option. 8-16 
Virtex. guide files. 8-3 
mapping 

description. 2-3. 2-9 
to input functions. 8-11 
Mask file. 16-39 
matching, buses. B-16 
MAXDELAY 

description. 6-62 
syntax. 6-76 
MAXSKEW 

description. 6-61 
syntax. 6-75 
MCS files. A-3 
MDF files. 8-5. 8-6. 9-3. A-3 
MEM files. 4-5. A-3 
Mentor 

Graphics ENRead. 19-5 


netlist writer. 6-4. 6-5. 6-23 
messages 

on screen displays. 1-4 
redirecting to files. 1-3 
symbols used. 1-2 
verbose mode. 20 - 10 . 21-8 
MFP files. 8-4.8-10, A-3 
-min option. SPEEDPRINT. 15-3 
MOD files. A-3 
module 

as black box in Verilog file. 20-5 
name, changing, 20-9 
mount points, 12-47 
MRP files 

description. 8-5. 8-25. A-3 
errors. 8-26 
example. 8-29 
sections. 8-26 
warnings. 8-26 
MSK files. 16-5. A-3 
MuItiLl.MX Cable. 2-33 
multiple 

buffets. 14-14 

groups, creating with TIMEGRP. 6-24 
iterations for PAR. 12-23. 12-24 
pads. 7-4 
PROM files. 17-8 
systems, running PAR. 12-42 
multiplication for time delays. 6-56 
multi-tasking 

mode, -m PAR option. 12-12 
option, for PAR. 12-42. 12-44 


-n option 

BitGen. 16-39 
NGD2ED1F. 19-6 
PAR. 12-13 
PROMGen. 17-6 
name 

check, logical DRC. 7-4 
legalization, in VHDL files. 21-5 
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qualifier*), predefined groups. 6-8 
qualifiers, wildcards. 6-9 
naming conventions 
for buses. B -16 
Verilog. 20-12 
VHDL. 21-19 
NCD files 

as guide file. 8-4. 12-9 
description. 8-2. 8-5. 18-5. A-3 
output file name. 8-13 
output from turns engine. 12-44 
reading with NCDRead. 1-7 
specifying for LCA2NCD. 9-2 
NCDRead. 1-7 
NCF files 

description. 4-5. A-3. B-4. B-10 
wildcard character;. 6-6 
-ne option. 20-6 
negative slack. 14-14 
net 

check, logical DRC. 7-3 
check, physical DRC. 11-1 
delay constraints. 14-12 
delay errors. 14-11 
skew constraints. 14-12 
skew errors, 14-11 
NET name. 6-6 
netlist 

bus matching. B-16 
data files (XFLOW). 22-28 
flattening. 18-10. 19-6 
translation. 4-3. B-13 
translation, description. 2-10 
writers, description. 2-24 
writers, invoking. 2-25 
writers, logical DRC. 7-2 
Netlister Launcher 
description. B-17 
system rules file. B-23 
treatment of timestamps. 4-8 
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nets 

critical. 16-41 
definition. 1-10 
delay. 6-62 
example. 1-11 

names, specifying with wildcards. 6-27 
skew. 6-61 
TNMs. 6-13. 6-14 
TPSYNC. 6-51 

net-specific, OFFSET constraint. 6-39 
networks 

automount points. 12-47 
for turns engines. 12-44 
problems, turns engine. 12-49 
new groups, from existing groups. 6-22 
NC.A files 

annotating device speed. 18-8 
description. 19-4. 20-4. 21-4. A-3 
specifying. 18-7 
N'GC files' 4-5. A-4 
NC.D files 

allowing unexpanded blocks. 4-10 
description. 4-6. 19-4. 20-4. 21-4. A-4 
input to MAP. 8-4 
logical constraints. 10-1 
removed logic. 8-27 
NC.D2ED1F 

-a option. 19-4 
-b option. 19-5 
-c option. 19-5 
description. 2-24. 19-2 
EDN files. A-2 
-f option. 19-5 
flow diagram. 19-3 
-i option. 19-5 
input design stages. 19-2 
input files. 19-4 
-1 option. 19-6 
-n option. 19-6 
options. 19-4 
output files. 19-4 
supported families. 19-1 
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syntax. 19-3 
-v option. 19-6 
-vpt option. 19-6 
-w option. 19-7 
XMM file. 19-7 
NGD2VER 

-lOps option. 20-5 

-aka option. 20-5 

-cd option. 20-5 

compile scripts. 20-12. 20-13 

description. 2-24. 20-2 

-f option. 20-6 

flow diagram. 20-3 

-gp option. 20-6 

input design stages. 20-2 

input files. 20-4 

LOG files. A-2 

-log option. 20-6 

-ne cation. 20-6 

-op option. 20-7 

options. 20-5 

oscillator functions. 20-11 

output files. 20-4 

-pf option. 20-7 

-pms option. 20-7 

-r option. 20-7 

SDF files. A-5 

-sdf option. 20-8 

setting global PRLD. 20-10 

-shm option. 20-8 

supported families. 20-1 

syntax. 20-3 

-tf option. 20-8 

-ti option. 20-9 

-tm option. 20-9 

-tp option. 20-9 

TV files. A-5 

-u option. 20-9 

-ul option. 20-10 

V files. A-5 

-verbose option. 20-10 

-w option. 20-10 


NGD2VHDL 

-a option. 21-5 
-aka option. 21-5 
description. 2-25. 21-2 
-f option. 21-5 
flow diagram. 21-3 

global set/reset and tri-state port. 21-9 
-gp option. 21-5 
identifiers. 21-19 
input design stages, 21-2 
input files. 21-4 
LOG files. A-2 
-log option. 21-6 
-op option. 21-6 
options. 21-5 
output files. 21-4 
-pf option. 21-6 
-pms option. 21-6 
-r option. 21-6 
-rpw option. 21-7 
supported families. 21-1 
syntax. 21-3 
-tb option. 21-7 
-te option. 21-7 
-ti option. 21-7 
-tp option. 21-8 
-tpw option. 21-8 
TV'HD files. A-5 
-verbose option. 21-8 
VHD files. A-5 
-w option. 21-9 
NGDAnno 

ALF files. A-l 

description. 2-23. 18-3 

-f option. 18-7 

FPGA Editor. 2-23 

global reset signals. 18-8 

guaranteed setup and hold. 18-10 

input files. 18-3. 18-5 

netlist flattening. 18-10 

NGA files. A-3 

-o option. 18-7 
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options. 18-7 
output files. 18-4. 18-5 
-p option. 18-7 
-s option. 18-8 
supported families. 18-1 
syntax. 18-4 

without mapped.ngm file. 8-25 
NC.DBuild 

-a option. 4-7 

BLD files. A-l 

bus matching. B-16 

bus matching, Virtex, B-17 

bus naming conventions. B-16 

converting netlists. 4-3 

converting netlists (detailed). B-13 

-dd option. 4-7 

description. 4-2 

-f option. 4-8 

file naming conventions. B-28 
flow diagram. 4-2 
input files. 4-4 
intermediate files. 4-6 
-1 option. 4-8 
logical DRC. 7-2 
NetlLsler Launcher. B-17 
NGD file. 4-2 
NGD files. A-4 
-nt option. 4-8 
options. 4-7 
output files. 4-6 
-p option. 4-9 
-r option. 4-9 
-sd option. 4-9 
supported families. 4-1 
syntax. 4-3 
system rules file. B-23 
-u option. 4-10 
-uc option. 4-10 
-ur option. 4-11 
NGM files. 8-5. 8-18. 18-5. A-4 


NGO files 

description. 4-6. A-4. B-4. B-10 
naming. 4-11 

overriding information. 4-9 
specifying a destination directory. 4-7 
NMC files. 4-5. 8-4. A-4 
nodelist files. 12-43 
-norun option 

XFLOVV, description. 22-14 
XFLOW, example. 22-15 
-nt option. 4-8 

o 

-o option 

DRC command. 11-3 
MAP. architectures. 8-7 
MAP. description. 8-13 
NGDAnno, 18-7 
PIN2UCF, 13-5 
PROMGen. 17-6 
TRCE. 14-7 

XFLOW, description. 22-15 
-oe MAP option 
architecures, 8-7 
description. 8-13 
OFFSET constraint 
advantages of. 6-36 
description. 6-36 
examples. 6-39 
global. 6-37 
net-specific. 6-39. 6-70 
syntax. 6-37. 6-39. 6-46 
types. 6-37 

with Timegroups. 6-44 
with T1MEGRP. 6-46. 6-73 
offset errors. 14-11 
OFFSET IN AFTER. 6-41 
OFFSET IN BEFORE. 6-40 
OFFSET OUT AFTER. 6-42 
OFFSET OUT BEFORE. 6-43 
-ol PAR option. 12-13 
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-op option 

NGD2VER. 20-7 
NCD2VHDL. 21-6 
OPT files. A-4 
optimization, logic 
description. 2-3 
effort. 8-13 
style. 8-14 

optimizing placement. 12-18 
option files 

example. 22-12 
-fit flow type. 22-7 
-implement flow type. 22-9 
locations, XFLOW'. 22-10 
relationship with flow types. 22-4 
XFLOW. 22-10 
option simulation files. 22-8 
options 

command line, entering, 1-2 
using spaces, 1-2 
-os option 

architecures. 8-7 
description. 8-14 
OscClk option, XC5200. 16-26 
Oscillator option. XC3XOOO. 16-8 
oscillators 

functions, NGD2VER. 20-11 
NGD2VER. 20-7 
NCD2VHDL. 21-6 
VHDL only. 21-14 
output director) 1 , write error. 4-12 
output files 

BitCen, 16-4 
DRC command. 11-3 
EDIF2NCD, B-4 
LCA2NCD, 9-3 
MAP. 8-5 

multiple iterations of PAR. 12-24 
name. NCD files. 8-13 
name. PROMGen, 17-6 
NGD2ED1F. 19-4 
NGD2VER. 20-4 


NGD2VHDL. 21-4 
NGDAnno. 18-5 
NGDBuild. 4-6 

overwriting. 16-41. 19-7. 20-10. 21-9 
PAR. 12-6. 12-23 
PARTGEN. 3-2 
PIN2UCF. 13-4. 13-5 
PROMGen. 17-3 
specifying for XFLOW. 22-15 
TRCE. 14-3. 14-11 
turns engine. 12-44 
XFLOW. 22-26 
XNF2NGD. B-10 
Output option. 16-18 
output pads, connecting to primitives. 7-3 
output signal names, register ordering. 8- 
19 

outputs. SPEEDPRINT. 15-4 
OutputsActive option 

XC4000 and Rattan. 16-19 
XC5200. 16-26. 16-27. 16-29 


-p option 

EDIF2NGD. B-6 
for part numbeis. 1-5 
LCA2NCD. 9-3 
MAP. architectures. 8-7 
MAP. description. 8-15 
NGDAnno, 18-7 
NGDBuild. 4-9 
PAR. 12-14 
PARTGEN. 3-4 
PROMGen. 17-7 
XFLOW, description. 22-16 
XFLOW, examples. 22-16 
XFLOW, package names. 22-16 
XNF2NGD. B-ll 
pack 

CLBs. 8-8 

registers in I/O. 8-16 
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package 

files, crealing. 3-5. 3-6 
names, XFLOVV. 22-16 
packages, listing with PARTGEN. 3-4 
pad check, logical DRC. 7-3 
PAD tiles. 12-35. A-4 
pads 

adding to lop-level port signals. 4-7. 
B-5 

connecting to top-level symbols. 7-4 
input, connecting to primitives. 7-3 
output, connecting to primitives. 7-3 
unbonded, connecting to primitives. 
7-4 

PAR 

-c option. 12-7 

command examples. 12-34. 12-55 

cost-based. 12-2 

-d option. 12-8 

delay tile. 12-33. 12-34 

description. 12-2 

-dfs option. 12-9 

displaying options. 12-7 

DLY files. A-l 

-e option. 12-9 

-f option, PAR. 12-9 

files, overwriting. 12-16 

flow diagram. 12-3 

-gf option. 12-9 

-gm option. 12 - 10 . 12-22 
guided. 12-20 
halting. 12-56. 12-57 
-i opium. 12-10 

ignoring timing constraints. 12-16 
input files. 12-6 

Intermediate Failing Timespec 
Summary. 12-26 
1TR files. A-2 
-k option. 12-10 
-kpaths option. 12-10 
-1 option. 12-12 
-m option. 12-12 
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multiple iterations. 12-23 

multi-tasking option. 12-42. 12-44 

-n option. 12-13 

-ol option. 12-13 

operation, placement. 12-18 

options. 12-7 

options summary. 12-17 

output files. 12-6. 12-23 

outputs for multiple iterations. 12-24 

-p option. 12-14 

PAD file. 12-35 

PAD files. A-4 

PCF files. 12-5 

-pi option. 12-14 

-r option. 12-14 

register placement. 8-19 

report file. 12-27. 12-30. A-4 

reports. Select IO. 12-32 

-rl option. 12-15 

running on multiple systems. 12-42 

-s option. 12-15 

saving results. 12-15 

Sparlan2, Select I/Os. 12-37 

strategies for guided designs. 12-21 

summaty report file. 12-25 

supported families. 12-1 

syntax. 12-5 

-t option. 12-16 

tilde in reports. 12-31 

timing driven, 12-2. 12-3 

-ub option. 12-16 

Virtex, Select I/Os. 12-37 

-w option. 12-16 

-x option. 12-16 

XP1 files. A-5 

PAR AUTOMNTPT. 12-47 

PAR AUTOMNTTMPPT. 12-47 

PAR M DEBUG. 12-48 

PAR M SETUPF1LE. 12-46 

Parallel Cable 111. 2-32 

parameter files. XFLOW option files. 22-11 

part names, XFLOW. 22-16 
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pari number option. 4-9. 8-15. B-6. B-ll 
part numbers 

commands. 1-4 
specifying in commands. 1-5 
PARTGEN 

description. 3-2 

-i option. 3-4 

input files. 3-2 

listing device attributes. 3-6 

options. 3-3 

output files. 3-2 

-p option. 3-4 

supported families. 3-1 

syntax. 3-2 

usage message. 3-3 

-v option. 3-5 

partlist.xct file. 3-2. 3-5. 3-6. 3-7 
path delay constraints. 14-12 
PATH physical constraint. 6-62 
paths 

definition. 1-11 
disabling tracing. 6-63 
enabling tracing. 6-63 
example. 1-12 
false. 12-11. 14-6 

loops, detecting with TRACE. 14-17 
tracing, block delay symbols. 6-64 
tracing, controlling. 6-63 
tracing, examples. 6-65 
tristate buffer. 12-12. 14-7 
pattern matching. 6-27. 6-28. 6-29. 6-70 
PCF files 

ALLCLOCKNETS keyword. 6-31. 6- 
32.6-61.6-63 

ALLPATHS keyword. 6-62 
BitGen. 16-3 
constraints entry. 10-3 
description. 8-5'. 10-1. 10-2. A-4 
flow diagram. 10-2 
in MAP. 8-3 
PAR. 12-5 

schematic constraints. 10-3 


specifying. 18-7 
summary reports. 14-23 
TNM NET. 6-22 
TRACE. 14-3 
PCI cores. 12-22 

PDStatusPin option, Spartan2. 16-33 
performance, design. 2-14 
PERIOD constraint 
description. 6-30 
example. 6-32 

example, derived clocks. 6-33 
forward tracing. 6-31 
paths. 6-30. 6-31 
syntax. 6-31. 6-72. 6-74 
with CLKDLLs. 6-34 
Persist option. 16-36. 16-37 
-pf option 

NGD2VER. 20-7 
NGD2VHDL. 21-6 

Physical Constraints File see PCF files 
physical DRC see DRC 
physical macro, definition. 1-12 
pin check, primitive. 7-5 
PIN files. 20-4. 20-7. 21-4. 21-6 
pin locking constraints 
P1N2UCF. 13-2 
user-specified. 13-3 
P1N2UCF 

description. 13-2 
flow diagram. 13-2 
input files. 13-4 
-o option. 13-5 
options. 13-5 
output files. 13-4 
pinlock.rpt file. 13-3 
pinlock.rpt files. A-5 
-r option. 13-5 
RPT files. A-5 
scenarios. 13-6. 13-7 
supported families. 13-1 
syntax. 13-4 
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pinlock.rpt file*. 13-3. A-5 
pins. Direct Input. 8-9 
-pi PAR option. 12-14 
Place and Route see PAR 
placement 
block. 2-9 

bypassing, -p PAR option. 12-14 
constructive. 12-18 
description. 2-3 
LCA2NCD. 9-3 
optimizing. 12-18 
placer 

cost tables. 12-16 
effort level. 12-14 
platforms, supported for 2.1i. 1-13 
-pms option 

NGD2VER. 20-7 
NGD2VHDL. 21-6 

port 

global reset signal as. 20-6. 21-5 
global tristate signal as. 20-9. 21-8 
post-synthesis functional simulation. 2-29 
PowerDown option. 16-20 
PovverdownPin option. Spartan2. 16-33 
PowerupCIk option. 16-31 
-pr MAP option 

architectures. 8-7 
description. 8-16 
predefined groups 
keywords. 6-7 
name qualifiers. 6-8 
TNMs, 6-11 

pre-implementation verification. 2-26 
pie-simulation translation. 2-21 
primitive pin check. 7-5 
primitive pins 

attaching TPSYNC. 6-52 
TNMs. 6-14 
primitive symbols 

attaching TPSYNC. 6-52 
TNMs. 6-15 
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primitives 

connecting to bidirectional pads. 7-4 
connecting to input pads. 7-3 
connecting to output pads. 7-3 
connecting to unbonded pads. 7-4 
description. 2-6 

priorities, of timing constraints. 6-67 
PRIORITY keyword. 6-58 
PRLD, setting global. 20-10 
PRM files. 17-3. A-4 
ProgPin option 
Spartan2. 16-33 
Virtex. 16-33 
XC5200. 16-28 
program blocks 

description. 22-21 
End Program construct. 22-22 
Executable construct. 22-21. 22-22 
Exports construct. 22-22 
Flag construct. 22-21 
Input construct. 22-21 
Program construct. 22-21 
Reports construct. 22-22 
variable assignments. 22-22 
Program construct. 22-21 
PROM 

files, bit swapping. 17-3. 17-4 
files, description. 17-3 
files, loading. 17-7 
files, multiple. 17-8 
formats. 17-7 
sizes. 17-7 
PROMCen 

-b option. 17-5 
-d option. 17-5 
description. 17-1. 17-2 
examples. 17-8 
EXO files. A-2 
flow diagram. 17-2 
-help option. 17-5 
HEX files. A-2 
input files. 17-3 
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MCS files, A-3 
-li option. 17-6 
-o option. 17-6 
options. 17-5 
output file name. 17-6 
output files. 17-3 
-p option. 17-7 
PRX1 files. A-4 
-r option. 17-7 
-s option. 17-7 
supported families. 17-1 
syntax. 17-3 
TEK files. A-5 
-u option. 17-7 
-x option. 17-8 
propagation delays 

clock-to-output. 14-19 
input-to-output. 14-20 
property. 6-4 

prorating constraints. 6-60 
PULLDOWN primitive. 7-3 
pulldowns 

adding to MO. 16-18 
adding to Ml. 16-18 
adding to M2. 16-18 
adding to Spartan2 MO pin. 16-32 
adding toSpartan2 Ml pin. 16-32 
adding toSpartan2 M2 pin. 16-33 
adding to SpartanZ TCK pin. 16-34 
adding to Spartan2 TDI pin. 16-34 
adding to Spartan2 TDO pin. 16-34 
adding toSpartan2 TMS pin. 16-35 
adding toTdoPin. 16-22 
adding to Virtex MO pin. 16-32 
adding to Virtex Ml pin. 16-32 
adding to Virtex M2 pin. 16-33 
adding to Virtex TCK pin. 16-34 
adding to Virtex TDI pin. 16-34 
adding to Virtex TDO pin. 16-34 
adding to Virtex TMS pin. 16-35 
PULLUP primitive. 7-3 


pullups 

adding to Cclk pin. 16-31 
adding to MO. 16-18 
adding to Ml. 16-18 
adding to M2. 16-18 
adding to Spartan2 MO pin. 16-32 
adding to Spartan2 Ml pin. 16-32 
adding to Spartan2 M2 pin. 16-33 
adding to Spartan2 ProgPin. 16-33 
adding to Spartan2 TCK pin. 16-34 
adding to Spartan2 TDI pin. 16-34 
adding to Spartan2 TDO pin. 16-34 
adding to Spartan2 TMS pin. 16-35 
adding toTdoPin. 16-22 
adding to Virtex MO pin. 16-32 
adding to Virtex Ml pin. 16-32 
adding to Virtex M2 pin. 16-33 
adding to Virtex ProgPin. 16-33 
adding to Virtex TCK pin. 16-34 
adding to Virtex TDI pin. 16-34 
adding to Virtex TDO pin. 16-34 
adding to Virtex TMS pin. 16-35 
longline. 12-19 
on PROGRAM pin. 16-28 
pulse width 

for ROC. 21-7 
for TOC. 21-8 

Q 

qualifiers, with IN Ms. 6-20 
question marks, pattern matching. 6-27 
quotation marks 

in file names. 4-12 
keywords. 6-11 
quotes, special characters. 6-6 


-r option 

ED1F2NGD, B-6 
MAP. architecures. 8-7 
MAP. description. 8-16 
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NGD2VER. 20-7 
NGD2VHDL. 21-6 
NGDBuild. 4-9 
PAR. 12-14 
PIN2UCF, 13-5 
PROMGen. 17-7 
XNF2NGD. B-12 
rawbits file. 16-5 
RBT files, 16-4. 16-5. A-5 
RCV files. A-5 
-rd option 

XFLOW, description. 22-16 
XFLOW, examples. 22-17 
ReadAbotl option 

XC4000 and Spartan. 16-20 
XC5200. 16-28 
ReadBack option 
Spartan2. 16-29 
Virtex. 16-29 
XC3X000. 16-9 
ReadCaptuie option 

XC4000 and Spartan. 16-20 
XC5200. 16-28 
ReadClk option 

XC4000 and Spartan. 16-21 
XC5200. 16-28 

re-entrant routing, -k Par option. 12-10 
register ordering 
disabling. 8-16 
flip-flop characteristics. 8-19 
output signal names. 8-19 
register placement. 8-19 
registers 

packing. 8-16 
with Timegroups. 6-44 
register-to-register paths. 14-13 
Relationally Placed Macros (RPMs). 2-6. 8- 
11 

report files 

DRC command. 11-3 
PAR. 12-25. 12-27. 12-30 
PAR delay file. 12-33. 12-34 


PAR PAD file. 12-35 
PIN2UCF. 13-5 
pinlock.rpt. 13-3 
summary TRACE report. 14-23 
TRACE.'14-15. 14-16 
verbose. 14-9 

XFLOW. 22-16. 22-17. 22-30 
Report Dir. 22-20 
Reports construct. 22-22 
requirements, timing. 6-2 
reserved names. B-3. B-8 
reserved words. 6-10 
Reset-On-Configuration see ROC 
Reset Time option, XC3XOOO. 16-9 
RISING keyword. 6-26. 6-69 
-rl PAR option. 12-15 
RLOC constraints. 8-11 
ROC 

description. 21-11 
specifying pulse width. 21-7 
ROCBUF, 21-13 
routed designs, scoring. 12-41 
routedelay. 14-13 
router 

effort level.-rl PAR option. 12-15 

iterations. 12-10 
route-throughs. 1-10 
routing 

cleanup. 12-19 
constructive. 12-18 
description. 2-3 
-r PAR option. 12-14 
re-entrant. 12-10 
RPT files. A-5 
-rpw option. 21-7 
RTL simulation. 2-28 

rules files see user rules file, system rules 
file 
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s 

-s option 

DRC command. 11-3 
NGDAnno, 18-8 
PAR. 12-15 
PROMGen, 17-7 
SPEEDPRINT. 15-3 
TRCE. 14-8 

schematic entry, description. 2-3. 2-5 
schematic-based simulation. 2-26 
schematics 

constraints, placement in PCF files. 

10-3 

entering timing specifications. 6-4 
SCR script files. A-5 
screen messages. 1-4 
script files 

fpga editor.ini. A-2 
fpga editor user.ini. A-2 
-sd option. 4-9 
SDF files 

description. 2-25. 20-4. 21-4. A-5 
outputting to specified path. 20-8 
-sdf option. 20-8 
search 

hierarchy, XFLOW. 22-2. 22-6 
patlis, specifying. 4-9 
Security option. 16-38 
SelecUOs. 12-32. 12-37 
separators, colons. 6-6 
serial modes. 16-37 
setup checking. 14-13 
setup times. 14-22 
setup/hold 

guaranteed. 14-21. 14-22 
NGDAnno. 18-10 
requirements. 14-19 
setuptime. 14-13 
-shm option. 20-8 

shm statements, in Verilog file. 20-8 
signal names, inverted. 6-6 


signal names, matching parent and child 
in Verilog file. 20-7 
in VHDL file. 21-6 
signals 

connecting to pads. 7-4. B-5 
making local to a device. 19-6 
merged. 8-27 
removed. 8-27 

SIMPRIM libraries, pointing to. 20-10 
simulation 

description. 2-3 
files, XFLOW. 22-8 
functional. 2-27 
global reset. 2-30 
HDL-based. 2-28 
in-circuit verification. 2-32 
MAP results. 8-23 
schematic-based. 2-26 
timing. 2-27 
with block delays. 2-26 
site, definition. 1-10 
sizes 

designs. 2-14 
of PROMs. 17-7 
-skew option. 14-8. 14-13 
skew, definition. 6-61 
slack. 14-13 
slices. 8-19 
soft macros. 2-6 
spaces, for options. 1-2 
Spartan2 

-c PAR option. 12-8 
-d PAR option. 12-8 
g BitGen option. 16-29 
lOB configuration. 6-61 
lOB configurations. 6-65 
MAP guide files. 8-3 
SelectlOs. 12-37 
slices. 8-19 

special characters, in quotes. 6-6 

speed setting. 8-9. 8-14 

speed, overriding with -s option, 14-8 
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SPEEDPRINT 

compatible families. 15-1 
description. 15-1 
example commands. 15-4 
example outputs. 15-4 
-min option. 15-3 
options. 15-3 
-s option. 15-3 
syntax, 15-2 
-t option, 15-3 
temperature. 15-3 
-v option. 15-3 
voltage. 15-3 

speeds, listing with PARTGEN. 3-4 
SRF file see system rules file 
STAMP model, comparing with verbose 
report. 14-33 
-stamp option. 14-8 
STARTBUF cell 

description. 21-10 
Virtex. 21-11 
startup 

Cclk. Nosync, lb-11 
CClk_Syne. 16-11 
-g BitGen option. 16-10 
STARTBUF. 21-10 
STARTBUF VIRTEX. 21-11 
STARTUP block, VHDL only. 21-9 
STARTUP VIRTEX block, VHDL 
only. 21-11 
Uclk_ Nosync. 16-11 
Uclk.Sync. 16-12 
STARTUP block, VHDL only 
description. 21-9 
Virtex. 21-11 
StartupClk option 
Spartan2. 16-30 
Virtex. 16-30 

XC4000 and Spartan. 16-21 
XC5200. 16-29 

static timing analysis, description. 2-31 
summaiy reports 


TRACE. 14-23 
without PCF file. 14-23 
SuperS mode. 16-37 
switches, XFLOW option files. 22-11 
symbols, in messages. 1-2 
synchronous designs 
data feedback. 2-17 
global clock distribution. 2-14 
other considerations. 2-15 
synchronous points. 6-50 
SyncToDone option. 16-21 
synthesis, macros. 2-6 
system requirements, turns engines. 12-45. 
12-46 

system rules file 
displayed. B-23 
example. B-26 
versus user rules. B-19 

T 

-t option 

BitGen. 16-39. 16-40 
PAR. 12-16 
SPEEDPRINT. 15-3 
-lb option. 21-7 
TckPin option. Spartan2. 16-34 
TckPin option. Virtex. 16-34 
TdiPin option, Spartan2. 16-34 
TdiPin option. Virtex. 16-34 
TdoPin option 
Spartan2. 16-34 
Virtex. 16-34 

XC4000 and Spartan. 16-22 
TDR files. A-5 
-te option. 21-7 
TEK files. A-5 

TEMPERATURE constraint. 6-60 
temperature. SPEEDPRINT. 15-3 
temporary mount points. 12-47 
testbench file. 21-7 
text-based entry, description. 2-3. 2-8 
-tf option. 20-8 
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through-points, using TPTHRU, 6-53 
THRU, with TPTHRU. 6-55 
-ti option 

NGD2VER 20-9 
NGD2VHDL, 21-7 
tied design file, 16-39 
tiedown. 16-5 
TIG 

description. 6-47 
example. 6-48 
syntax. 6-47. 6-71. 6-74 
tilde 

in delay lile. 12-33 
in PAR report files. 12-31 
in TRACE report. 14-17 
time delays 

division. 6-56 
in TI.MESPECs. 6-55 
multiplication. 6-56 
Timegroups 

with inverters. 6-45 
with OFFSET. 6-44 
with registers. 6-44 
TIMEGRP 

attributes, placement. 6-24 
combining multiple groups. 6-24 
creating groups by exclusion. 6-25 
creating new groups. 6-22 
creating various groups. 6-24 
defining latch subgroups. 6-27 
grouping by exclusion. 6-25 
groups by clock sense. 6-26 
groups by pattern matching. 6-27 
primitive. 6-23. 6-24 
relation to TIMESPEC. 6-23 
reserved words. 6-10 
sample schematic. 6-58. 6-59 
syntax. 6-22. 6-23. 6-69 
with MAXDELAY. 6-63 
with MAXSKEW. 6-61 
with OFFSET. 6-46. 6-73 
with PERIOD. 6-31. 6-32 


TIMESPEC 

pattern matching, 6-29 
primitive, 6-4 
primitive, keywords. 6-5 
PRIORITY keyword, 6-58 
relation to TIMEGRP. 6-23 
sample schematic. 6-58. 6-59 
syntax. 6-71 
time delays. 6-55 
timestamp option. 4-8 
timing analysis 
advanced. 14-1 
-dfs option. 12-9. 14-4 
-kpaths option. 12-10. 14-5 
timing constraints 

compatible families. 6-1 
DROP .SPEC. 6-66 
entering in files. 6-6 
entering in schematics. 6-4 
entering on schematics. 6-4 
FROM-TO. 6-48 
ignoring in PAR. 12-16 
lOB registers. 6-3 
MAXDELAY. 6-62 
MAXSKEW. 6-61 
OFFSET. 6-36 
PERIOD. 6-30 
predefined groups. 6-8 
priorities. 6-67 
reserved words. 6-10 
specifying. 6-2. 12-3. 12-4 
TIG. 6-47 
TIMEGRP. 6-22 
TIMESPEC use. 6-8 
TNM NET. 6-21 
TNMs. 6-10 
TPSYNC. 6-50 
TS attributes. 6-55 
user-deftned groups. 6-10 
timing errors 

net delay. 14-11 
net skew. 14-11 
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offset. 14-11 
path delay, 14-11 
timing points, specifying. 6-50 
timing properties, annotating to instances, 
19-5 

timing reports, description. 14-16 
timing requirements. 6-2 
timing scores. 12-30 
timing simulation 

data (XFLOW). 22-29 
description. 2-27 
post-implementation. 2-29 
timing specification see also timing 
constraints 
timing specifications 

entering on schematics. 6-4 
in constraint files. 6-6 
overview. 2-9 

timing verification. TRCE. 14-12 
timing-driven PAR. 12-2. 12-3 
-tm option. 20-9 
TmsPin option. 16-35 
TNM constraint 

CLKDLLs. 6-34. 6-35. 6-36. 12-27 
description. 6-10 
forward tracing. 6-12. 6-14. 6-20 
grouping flip-flops. 6-18 
grouping flip-flops and latches. 6-18 
input pads. 6-12 

on clock pin grouping flip-flops. 6-20 

on macro pins. 6-15 

on macro symbols. 6-16 

on macros. 6-14 

on nets. 6-14. 6-18 

on nets to group flip-flops. 6-19 

on pins. 6-18 

on primitive symbols. 6-15 
path tracing. 6-11 
placed on nets, 6-13 
predefined groups. 6-11 
primitive pins. 6-14 
qualifiers. 6-20 


storage elements. 6-21 
syntax. 6 - 10 . 6-68 
user-defined groups. 6-10 
TNM NET constraint 

CLKDLLs. 6-34. 6-35. 6-36. 12-27 
description. 6-21 
example. 6-22 
PCF files. 6-22 
UCF syntax. 6-21 
user-defined groups. 6-21 
with nets. 6-22 
TOC 

description. 21-13 
specifying pulse width. 21-8 
TOCBUF, 21-14 
-tp option 

NGD2VER. 20-9 
NGD2VHDL. 21-8 
TPSYN'C 

attached to net. 6-51 
attached to output macro pin. 6-51 
attached to primitive pins. 6-52 
attached to primitive symbols. 6-52 
defining synchronous points. 6-50 
description. 6-50 
restrictions. 6-53 
syntax. 6-50. 6-73 
with FROM-THRU. 6-54 
with FROM-TO. b-54 
TPTHRU 

defining through points. 6-53 
description. 6-50 
example. 6-55 
syntax. 6-73 
with FROM-TO. 6-SI 
with THRU. 6-55 
-tpw option. 21-8 
TRACE 

description. 2-31. 14-2 
detecting path cycles. 14-17 
error report. 14-28. 14-29 
falling signals. 14-17 


Development System Reference Guide 


Index-27 




Development System Reference Guide 

flow diagram. 14-2 
hailing. 14-38 
PCF files. 14-3 
reports. 14-15. 14-16 
rising signals. 14-17 
summaiy report, 14-23 
supported families. 14-1 
timing verification. 14-12 
TVVR files. A-5 
verbose report. 14-33. 14-34 
tracing, forward. 6-12. 6-14. 6-20 
TRANSHI keyword. 6-27. 6-69 
translation 

of netlist. 4-3 
pre-simulation. 2-21 
translation options 
description. 2-26 

pre-implementation verification. 2-26 
simulating with block delays, 2-26 
TRANSLO keyword. 6-27. 6-69 
TRCE 

-a option. 14-4 

DATA files. A-l 

data sheet reports. 14-19 

-dfs option. 14-4 

-e option. 14-5 

example commands. 14-10 

-f option. 14-5 

input files. 14-3. 14-10 

-kpaths option. 14-5 

MOD files. A-3 

-o option. 14-7 

options. 14-4 

output files. 14-3. 14-11 

-s option. 14-8 

-skew option. 14-8 

-stamp option. 14-8 

syntax. 14-2 

-u option. 14-9 

-v option. 14-9 


tristate 

buffer paths. 12-12. 14-7 
enable signals. 12-11. 14-6 
Tri-State-On-Configuration cell see TOC 
TS attributes 

delay time units. 6-55 
description. 6-4 
examples. 6-56 
placement. 6-50 
syntax. 6-5. 6-72 
time delays, 6-55 
TSidentifier constraint 
in PCF 

with ALLCLOCKNETS. 6-31. 6-32 
with MAXDELAY, 6-62 
-tsim flow type 

option simulation files. 22-8 
XFLOW, description. 22-10 
XFLOW, example. 22-10 
TIL. 16-8. 16-23 
turns engine 

debug mode. 12-48 
debugging. 12-49 
description. 12-42 
environment problems. 12-49 
environment variables. 12-47 
halting with CONTROL-C. 12-50 
input files. 12-43 
limitations. 12-45 
NCD output file. 12-44 
network problems. 12-49 
nodelist file. 12-43 
output files. 12-44 
running on networks. 12-44 
screen output. 12-50 
starting from command line. 12-48 
system requirements. 12-45. 12-46 
TV files. 20-4. 20-8. A-5 
TVHD files. 21-4. 21-7. A-5 
TWR files. A-5 
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u 

-u option 

BitGen. 16-41 
MAP. architectures, 8-7 
MAP. description. 8-16 
NGD2VER. 20-9 
NGDBuild. 4-10 
PROMGen, 17-7 
XNF2NGD. B-12 
-u TRCE option. 14-9 
-ub PAR option. 12-16 
-uc option. 4-10 
UCF files 

as NGDBuild input. 4-5 
description. 5-1 
logical constraints. 5-1 
specifying. 4-10 
wildcard characters. 6-6 
XFLOVV. 22-19 
UCF syntax, TNM NET. 6-21 
Uclk.Nosync. 16-11 
Uclk_Sync. 16-12 
-ul option. 20-10 

unbonded pads, connecting to primitives. 

7-4 

uncovered paths, for TRCE. 14-9 
underbars. 8 - 20 . 8-21 
unnamed components, in LCA files, 9-4 
unused interconnects. 16-39. 16-40 
unused logic, keeping. 8-16 
-ur option. 4-11 
user command blocks 
description. 22-22 
examples. 22-23 
user input files, XFLOVV. 22-18 
user rules file 

examples. B-27 
format. B-20 
key values. B-22 
keys. B-20 
specifying. 4-11 
versus system rules. B-19 


user-defined groups 
TNM NET. 6-21 
TNMs. 6-10 
UserlD option. 16-38 

V 

V files. 20-4. A-5 
-v option 

DRC command. 11-3 
NGD2ED1F. 19-6 
PARTCEN, 3-5 
SPEEDPRINT. 15-3 
TRCE, 14-9 

variable assignments, XFLOVV. 22-22 
vendor toolset, specifying. 19-6 
-verbose option 

NCD2VER, 20-10 
NGD2VHDL, 21-8 
verbose reports 

comparing with data sheet report. 
14-33 

comparing with STAMP model. 14-33 
TRACE. 14-9. 14-33. 14-34 
verification 

timing, with TRCE. 14-12 
tools. 2-21 
Verilog 

compile scripts. 20-13 
identifier. 20-12 

Verilog simulator, terminating. 20-11 

VHD files. 21-4. A-5 

VHDL 

files, bus order. 21-18 
identifiers. 21-19 
Virtex 

bus matching. B-17 
-c PAR option. 12-8 
-d PAR option. 12-8 
-g BitGen option. 16-29 
lOB configuration. 6-61 
lOB configurations. 6-65 
MAP guide files. 8-3 
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SeleclIO standard. 12-32 
SelectlOs. 12-37 
slices. 8-19 

VM6 files, M1J versions. 22-27 
VOLTAGE constraint, 6-60 
voltage, SPEEDPRINT. 15-3 
-vpt option, 19-6 

w 

-w option 

BitGen. 16-11 
LCA2NCD, 9-4 
NGD2ED1F. 19-7 
NGD2VER, 20-10 
NGD2VHDL. 21-9 
PAR. 12-16 
warnings 

DRC command. 11-5 
MRP files. 8-26 
-wd option 

-with -ed option. 22-14 
XFLOW, description. 22-17 
XFLOW, examples. 22-18 
wildcards 

asterisk. 6-27 
in UCF or NCF files. 6-6 
name qualifiers. 6-9 
question mark. 6-27 
specifying net names. 6-27 
working directory, XFLOW. 22-17. 22-18 

X 

-x option 

PAR. 12-16 
PROMGen. 17-8 
X8 mode. 16-37 
XChecker cable. 2-32 
XFLOW 

annotated netlist data. 22-28 
application data files. 22-30 
compatible families. 22-1 


-config flow type. 22-6 

CPLD programming data. 22-27 

CPLD report flies. 22-31 

default flow files. 22-3 

description. 22-2 

-ed option. 22-14 

file search strategy. 22-10 

-fit flow type. 22-7 

flow diagram. 22-3 

flow files. 22-19 

flow type examples. 22-5. 22-6 

flow types. 22-6 

flow types and option files. 22-4 

FLW files. A-2 

FPGA programming data. 22-27 
FPGA report files. 22-30 
-fsim flow type. 22-8 
functional simulation data. 22-28 
guide data. 22-29 
-h option. 22-14 

-implement flow type. 22-5. 22-9 
input files. 22-18 
netlist data files. 22-28 
-norun option. 22-14 
-o option. 22-15 
OPT files. A-4 
option file locations. 22-10 
option flies 

description. 22-10 
example. 22-12 
Files. 22-11 
parameter files. 22-11 
switches. 22-11 
option simulation flies. 22-8 
output files. 22-26 
-p option. 22-16 
-rd option. 22-16. 22-17 
Report Files. 22-16. 22-17 
search hierarchy. 22-2 
specifying output files. 22-15 
syntax. 22-4 
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table of options. 22-5 
timing simulation data. 22-29 
-tsim flow type. 22-10 
UCF files. 22-19 
user input files. 22-18 
VM6 files. 22-27 
-wd option. 22-17. 22-18 
working directory. 22-17. 22-18 
XFLOWPATH, 22-2 
XFLOWPATH. 22-2 
XMM file 

description. 19-4. 19-7 
generic file format. 19-7 
generic simulator. 19-7 
Mentor Graphics simulator. 19-7 
-v option. 19-7 
Viewlogic simulator. 19-7 
XNF files 

description. A-5. B-10 
specifying as top-level netlist. B-12 


XNF2NGD 

description. B-7 
-f option. B-10 
flow diagram. B-8 
input files. B-10 
-1 option. B-ll 
output files. B-10 
-poption. B-ll 
-r option. B-12 
supported families. B-7 
syntax. B-9 
-u option. B-12 

XP1 

files. A-5 

report. 12-6 

XTF files. A-5 

z 

-z option. 11-4 
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